當我們采用面向對象的編程語言來設計類的時候，我們設計的大部分類應該是勻稱并且均勻的。

類本身應該是勻稱的

我們知道，類既有狀態，又有行為。在多數面向對象的語言中，狀態由類的字段來承載，而行為通過類的方法來實現。通過方法調用可以改變類的內部狀態，而類的內部狀態又可以影響方法的調用結果。

類應該是勻稱的，在一個類的內部，它的字段數量和方法數量之間應該維持一個合適的比例。只有字段沒有方法的類和只有方法沒有字段的類都不應該存在，或只有少量存在。類既不應該太瘦高，也不應該太矮胖。理想狀態下，一個類中的每個方法都應該用到這個類的所有或者大多數字段，否則這個類就明顯缺乏內聚性，應該拆分為兩個或多個類。

只有字段沒有方法的類的典型例子就是貧血模型中的領域類。它們上面沒有定義任何有意義的方法，只有getter和setter這樣的狀態封裝器，嚴格來說不屬于方法。這樣的類只是披著類的外衣的數據結構。

只有方法沒有字段(或只有極少字段)的類的典型例子是各種門面(Facade)類，以及DateUtils、CollectionUtils這樣的工具類。這樣的類里面的方法明顯缺乏內聚性。

只有狀態的類和只有方法的類都違反了面向對象的基本原則。在面向對象的范式中，類是狀態和行為的統一。雖然在函數式編程范式中，數據和行為分離是得到鼓勵的，但是既然我們仍然采用OO編程范式，就應該繼續遵循OO的原則。

項目中的類應該是均勻的

項目中的類應該是均勻的。各個類的規模應該相差不大，復雜度相當，擔任有限數量的職責。避免出現成千上萬行代碼的上帝類和大量只有幾行代碼的塵埃類。

上帝類存在于很多設計不良的項目中。我曾經參與過的一個遺留項目，發現其中有一個類占了整個項目代碼行數的三分之一以上！系統每次擴展都要修改這個類，往上面添磚加瓦。這個類達到了“全知”(了解和調用所有底層組件)、“全能”(參與實現系統的全部功能)的程度，稱為“上帝類”當之無愧。可惜它無法達到“全善”，實際上它是萬惡之源。

系統中所有的類都應該只承擔有限數量的職責，各個類的大小應該相差不大。高層的類只負責協調底層的多個類完成一個高階功能而不是親自實現所有細節，每個低層類應該只實現高層類委托的一個子任務。高層類和低層類的責任都是有限的。

現實生活中不也是這樣嗎？部長和科員級別相差很大，但是兩者的工作量不會有數量級的差別。上天給每個人都是每日24小時，“日理萬機”是不可能的。部長負責工作的分解和整合，工作任務層層分解和分派下去，每個科員則負責實現工作的一小部分。我們不需要選取一個巨人或神仙來擔任部長。

類本身應該是勻稱的，類之間應該是均勻的。不符合這個原則的項目必然存在不同程度的設計欠賬，將來也許需要償還高額的利息——如果它還有將來的話。

總結

以上是生活随笔為你收集整理的80070583类不存在_原创 | 类应该是匀称和均匀的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。