盡管單一職責的這個概念比較容易理解，但是在實際操作的時候卻沒有一個明確的邊界，也就是說要憑感覺。就比如上文中的音箱的例子，如果在隻有充電和播放音樂的這種情況下，我們也可以將其寫入到一個類中。但是如果功能變多，比如增加瞭電量展示、涓流充電等功能，那顯然我們更應該把這些方法放到一個電池的類中，並將電量的屬性也放進去。

所以從可實施的角度上來說的話，我們可以通過兩種方法來幫我判斷這個方法是否滿足單一職責：

解釋來說，如果無法用一個對象名來描述這個類的話，而隻能通過一些通用概念（如處理器、執行器、管理器）來對他進行描述的話，就說明這個類的功能並不單一（當然如果本身代碼規範就是這麼定義的就另當彆論）。而如果無法用一兩句話來描述類的功能，或者必須用大量的“與”、“或”等詞來對描述做串聯，就說明其承擔瞭太多的功能瞭，我們應該將其拆分一下。

內聚

我們在進行麵對對象編程的時候經常說的就是類需要“高內聚、低耦閤”。我們把類中的方法操作類中的屬性稱做方法與屬性的關聯的話，那麼關聯越多的類就是越內聚的。極端一點的話，如果類內所有的方法都使用所有的類屬性的話，那麼這個類是最為內聚的。實際情況並不總是如此理想，所以我們可以根據這種關聯關係來判斷類中的內容是否足夠內聚。

所以，如果你發現在在寫完類瞭之後部分方法隻與部分屬性産生關聯，而其他方法則與另外的屬性産生關聯，就說明這兩部分之間是沒有內聚性的。那麼我們就可以將其拆分為兩個類，而這兩個類之間將更加的內聚：方法與屬性互相依賴稱為瞭一個整體。

當我們通過內聚性來分析類後，可能會將一個大類，拆分為多個小類。這樣會增加類的數量從而增加類的復雜性，同時也會讓整體的代碼變多。但是類本身可以通過包路徑來進行分類，所以這種拆分我認為是比較閤理的。

可擴展

對於一些有擴展需求的類，盡管他們可能滿足單一職責以及內聚屬性。但是由於這種類本身的擴展性，導緻我們會在新的業務需求的時候頻繁地對這種類進行修改與新方法的增加。這種修改導緻的問題是在每一次修改代碼或者新增方法的時候都無法保證不會對原有的功能造成影響。雖然我們可以通過單元測試或者集成測試來驗證我們的修改，但是這都會增加我們的工作量。

所以，對於可能會頻繁修改、並進行業務追加的方法類，我們需要特彆的為其保留擴展性。我們可以通過實現統一接口或者繼承抽象類、父類的方法，來獲得多個不同擴展能力的子類，而這些子類我們也可以通過策略模式或者責任鏈模式來組織。

對於類來說，對其進行擴展總是好與對其直接進行修改。

可測試

關於這個角度，其實是源於我的另一個問題，就是在傳統的三層框架下，中間的service層我們是否需要編寫一層接口（interface）。我原來的認知是，實際上在絕大多數的情況，這個service我們是不會再進行其他實現的，所以單獨寫一個接口然後再增加對應的Impl隻會讓我們在擴展方法的時候更加的繁瑣。

但是現在我發現瞭直接的用處，那就是：支持瞭單元測試的進行。

如果我們直接依賴具體的細節，就會對我們的測試帶來挑戰。具體來說，如果我們依賴於一個具體的類的實現的話，那麼當我們希望針對其中的細節進行測試的話我們就要對細節之外的內容進行調整，可能包括：係統時間、數據庫字段等內容。但如果我們是使用接口對servce進行調用，那麼在我們測試的時候就可以通過直接編寫測試用的service來實現預期的返迴內容。從而大大簡化進行測試的難度。

我們通過接口降低瞭係統之間的耦閤度，讓類之間的關係更好理解，也便於測試的進行。而這也是我們的依賴倒置原則（DIP），我們針對抽象編程，讓其不依賴與具體細節，這樣當我們需要調整細節的時候也不會影響上層內容。

最後

我們在coding的過程中總是在進行類的編寫，本篇文章對類的一些編寫注意事項進行瞭描述，在編寫過程中主要需要注意類的：內部屬性方法順序、類的職責是否單一、是否足夠內聚、是否支持擴展、是否可以進行單元測試。盡管這並非全部需要注意的內容，但如果可以根據這些引發思考便足夠瞭。