單一職責原則
優勢：
因為物件導向的程式設計是推崇面向介面的程式設計的，我們對外暴露的方法也最好是以介面的形式定義，再由具體的類進行實現，諸多的好處就不再贅述，我們下面就基於乙個簡單的場景進行設計，體現單一職責的好處:
比如pear是一家電子產品商，它要生產pad,phone,watch等裝置，但是有一些重複的功能，如果分別設計一套，很顯然並不划算，那麼介面定義上我們就可以根據功能劃分設定單一職責的介面:
介面的定義
//可以撥打**
inte***ce
callable
//可以觸控控制
inte***ce
touchable
//可以訊息提醒
inte***ce
messagepromptable
//可以接入鍵盤
inte***ce
keyboardmatchable
class
standardcall
implements
callable
}class
standardtouch
implements
touchable
}class
standardpromt
implements
messagepromptable
}class
standardmatch
implements
keyboardmatchable
}
//在宣告這台手機時我們就明確知道了它的功能
class myphone implements callable,messagepromptable,touchable
@override
public
void
prompt()
@override
public
void
touch()
}public
class
srptest
}
class
mypad
implements
touchable,keyboardmatchable
@override
public
void touch()
}
對於單一職責原則，介面一定要做到單一職責，類的設計盡量做到只有乙個原因引起變化
class
callandprompt
implements
callable,messagepromptable
@override
public
void prompt()
}//在宣告這台手機時我們就明確知道了它的功能
class
myphone
implements
callable,messagepromptable,touchable
@override
public
void prompt()
@override
public
void touch()
}
設計模式原則 單一職責原則
定義 乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。即 不要存在多於乙個導致類變更的原因。通俗的說，就是乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 ...
設計模式原則 單一職責原則
對類來說的，即乙個類應該只負責一項職責。假如類a負責多項職責，當其中一項職責需求發生變更時，可能對其他職責的執行造成影響。例如 類a負責實現 訂單資料持久化 職責 和 使用者資料持久化 職責，那麼當我們需要修改 使用者資料持久化 需求時，由於 糅雜在乙個類裡，可能會對 訂單資料持久化 的職責造成影響...
設計模式原則 單一職責原則
1.概念 對類來說的，即乙個類應該只負責一項職責。如類a負責兩個不同職責 職責1，職責2。當職責1需求變更而改變a時，可能造成職責2執行錯誤，所以需要將類a的粒度分解為a1，a2。2.問題的提出 package com.atguigu.principle.singleresponsibility p...