不完整的抽象

抽象未支援所有互補或相關的方法時，將導致這種壞味。

為什麼要有完整的抽象？

一種重要的抽象實現手法是建立內聚而完整的抽象。抽象未支援相關的方法時，可能會影響抽象的內聚性和完整性。如果抽象只支援部分相關的方法，其使用者就可能不得不自己去實現其他的功能。客戶程式可能嘗試直接訪問抽象的內部實現細節，此時帶來的副作用是違反封裝原則。

一些常見的互補方法對

Min/Max	Open/Close	Create/Destroy	Get/Set
Read/Write	Print/Scan	First/Last	Begin/End
Start/Stop	Lock/Unlock	Show/Hide	Up/Down
Source/Target	Insert/Delete	First/Last	Push/Pull
Enable/Disable	Acquire/Release	Left/Right	On/Off

現實考慮

###禁止特定行為

設計人員可能有意識地做出不提供堆成或配套方法的設計決策。例如在只讀集合中，包含Add()方法，而不包含Remove()方法。

使用單個方法而不是成對的方法

例如用SetEnabled(bool)替換Enable()和Disable(),傳入true代表啟用，fasle代表禁用。

多方面抽象

抽象被賦予不止一項職責時，將導致這種壞味。

##為什麼不可以有多方面抽象？

單一職責原則指出，抽象必須承擔單一而明確的職責，且必須完全封裝該職責。抽象承擔了多種職責時，意味著它將受多種原因的影響而需要修改，設計的修改頻率與其缺陷數之間存在很強的正相關關係。這意味著多方面抽象存在的缺陷可能更多。

多方面抽象的潛在原因

通用抽象

引入使用通用名（如Item,Order,Product，Image）的抽象時，它常常會成為佔位符，用於提供所有相關（但未必屬於它）的功能。抽象的命名代表了這個抽象的職責，命名太通用，隨著系統的迭代，抽象會慢慢承擔多種職責。感同身受！！！

未定期重構

對類進行了大量修改而沒有定期重構，長此以往，可能就會在類中引入了額外的職責。

混合關注點

沒有對關注點分離給予足夠的重視。

重構建議

類承擔了多種職責時，就不是內聚的。可以使用“提取類”來進行重構。

未用的抽象

建立的抽象未用（未被直接使用或繼承）時，將導致這種壞味。有以下兩種表現形式：

• 未引用的抽象：未用的具體類
• 鰥寡抽象：沒有任何派生抽象的介面/抽象類

為什麼不可以有未用的抽象？

設計中的抽象未被使用，就沒有發揮任何作用，因此違反了抽象原則。未實現的抽象類和介面時多餘的或憑空想象出來的概括，因此是不需要的。

##未用的抽象潛在原因

憑空想象的設計

試圖設計”永不過時”的系統或在其中包含”未來可能用得著”的抽象時，將導致這種壞味。

不斷變化的需求

需求不斷變化，為滿足早期需求而建立的抽象可能已經不再需要。如果將其留在設計中，它將變成未用的抽象。

維護過程中留下的垃圾

維護或重構時，如果不清理舊的抽象，可能留下未引用的抽象。這點深有體會，所以一直要求組員在重構的過程中，一定要把舊程式碼刪除。如果不這樣做，過期的和未用的程式碼將導致程式碼庫急劇膨脹，重構的程式碼和未重構的程式碼糾纏在一起，程式碼的可理解性、閱讀體驗極差。而且如果你重構的舊程式碼你不負責刪除，其他人就更不知道如何下手了，久而久之這些舊程式碼就會變成BUG的溫床。註釋掉舊程式碼也不是一個好的選擇，太影響閱讀體驗。其次，現在的程式碼版本控制工具功能強大，即使刪除錯了程式碼，也可以通過版本控制工具找回。所以舊程式碼必須死。

擔心破壞既有程式碼

不確定是否還有其他程式碼在使用想要刪除的舊程式碼。

重構建議

將未用的抽象從設計中刪除。對於可能還有客戶程式在使用的API，直接刪除不可行，可將這些抽象標記為“過期的“或”已摒棄”,明確地指出在新開發的客戶程式中不得使用它們。

[Obsolete]
public class Report
{
}
複製程式碼

現實考慮

類庫和框架通常以抽象類或介面的方式提供擴充套件點，這些抽象類可能在庫或框架中未被使用，但它們是供客戶程式使用的擴充套件點，因此不屬於未用的抽象。

重複的抽象

兩個抽象的名稱、實現或兩者相同時，將導致這種壞味。

• 名稱相同

  兩個不同的抽象重名將影響可理解性。

• 實現相同

  多個抽象的成員定義在語義上相同，但在設計上沒有捕獲並使用這些實現中相同的元素。在繼承層析結構中，如果多個兄弟抽象的實現相同，可能意味著存在的是”未歸併的層次結構”壞味。

• 名稱實現都相同

##為什麼不可以有重複的抽象？

重複程式碼是軟體萬惡之首。所以我們要極力避免重複。

如果多個抽象的名稱相同，將影響設計的可理解性：客戶程式碼開發人員將不知道使用哪個抽象。

如果多個抽象的實現相同（程式碼相同），將難以維護：修改其中一個抽象的實現時，常常需要修改其它所有重複抽象的實現。這不僅增加了修改負擔，還可能引入難以發現的微小BUG。為縮小修改範圍，必須儘可能避免重複。

重複的抽象潛在原因

複製貼上程式設計手法

CV程式設計師複製並貼上程式碼，而不應用合適的抽象。

即興維護

經過多年的修復或改進後，軟體將包含”殘留”，其中有大量重複的程式碼。

交流不暢

不同時期通常由不同的人員負責維護軟體，他們對軟體的瞭解不徹底，編寫了原來就有的類或方法，導致軟體包含重複的程式碼。

###類被宣告為不可擴充套件的

類被宣告為不可擴充套件的，無法重用程式碼，只能複製程式碼，建立修訂版本。

重構建議

對於名稱相同的重複抽象，可以將其中一個抽象改為不同的名稱。

對於實現相同的重複抽象，如果實現完全相同，可將其中一個抽象刪除。如果實現稍有差異，可將相同的實現歸併到另一個類中：這可以是層次結構中的基類，也可以是重複的抽象可引用或使用的既有類或新類。

現實考慮

適應變化

導致重複抽象的一個原因是，要同時支援同步和非同步變種。

在不同的上下文中使用相同的型別名

對於大型系統，建立完全統一的領域模型要麼不可行要麼不划算。領域驅動設計提供的一種解決方案是，將大型系統分成多個”界限上下文”。採用這種方式，不同上下文中的模型可能包含同名的型別，但是這是可以接受的。

語言未提供重複避免支援

在JDK中，有很多的重複的方法和類，這是因為沒有對基本型別提供泛型支援。但是在.Net中就不會有這麼多重複的方法和類，因為C#對基本型別提供了泛型支援。

參考：《軟體設計重構》