在幾乎所有我解釋了 面向對象程序設計 觀點的演講中，都有人分享這樣的評論：“如果我們遵循您的建議，我們將有很多小類。” 我的回答總是一樣：“我們當然會的，那太好了！” 老實說，即使您不能考慮擁有“許多類”是一種美德，也不能稱其為任何真正面向對象的代碼的缺點。 但是，可能會出現類成為問題的情況。 讓我們看看何時，如何以及如何做。

最好的《 Eldíala la bestia》（1995年），álexde la Iglesia

前面提到過許多“規則”，如果應用這些規則，顯然會導致大量的類，包括：a）所有公共方法必須在接口中聲明； b）對象的屬性不得超過四個（ Elegant Objects的 2.1節）； c） 不允許使用靜態方法； d）構造函數必須是無代碼的； e）對象必須公開少于五個公共方法（ Elegant Objects的 3.1節）。

當然，最大的擔憂是可維護性：“如果我們有300個較短的類，而不是50個較長的類，那么代碼的可讀性就會降低。” 如果您設計不正確，這肯定會發生。

OOP中的類型（或類）構成了您的詞匯表 ，它解釋了代碼周圍的世界-代碼所處的世界。詞匯表越豐富，代碼的功能就越強大。 您擁有的類型越多，您對世界的理解和解釋就越好。

如果您的詞匯量足夠大，您將說出以下內容：

閱讀桌上的書。

如果詞匯量少得多，則相同的短語聽起來像：

用那個東西上的東西來做。

顯然，閱讀和理解第一個短語會更容易。 OOP中的類型也會發生同樣的情況：您擁有的類型越多，代碼就越具有表現力，亮度和可讀性。

不幸的是，在設計Java和許多其他語言時并未考慮到這一概念。 包，模塊和名稱空間并沒有真正的幫助，并且我們通常以諸如AbstractCookieValueMethodArgumentResolver （Spring）或CombineFileRecordReaderWrapper （Hadoop）之類的名稱結尾。 我們正在嘗試將盡可能多的語義打包到類名中，以使他們的用戶不會懷疑。 然后，我們嘗試將盡可能多的方法放在一個類中，以使用戶的生活更輕松； 他們將使用其IDE提示找到正確的提示。

除了OOP，這什么都沒有。

如果您的代碼是面向對象的，則您的類必須很小，它們的名稱必須是名詞，而它們的方法名稱則只能是一個單詞。 這是我在代碼中所做的以實現此目的：

接口是名詞 。 例如， Request ， Directive或Domain 。 沒有例外。 類型（在Java中也稱為接口 ）是我詞匯表的核心部分。 他們必須是名詞。

類帶有前綴 。 我的課程總是實現接口。 因此，我可以說它們始終是請求，指令或域。 我一直希望他們的用戶記住這一點。 前綴幫助。 例如， RqBuffered是一個緩沖的請求， RqSimple是一個簡單的請求， RqLive是一個代表“實時” HTTP連接的請求， RqWithHeader是一個帶有附加頭的請求。

一種替代方法是使用類型名稱作為類名稱的中心部分，并添加一個解釋實現細節的前綴。 例如， DyDomain是一個將其數據持久存儲在DynamoDB中的域。 一旦知道了Dy前綴的含義，就可以輕松了解DyUser和DyBase DyUser 。

在中型應用程序或庫中，您將需要記住的前綴多達10至15個，僅此而已。 例如，在Takes框架中 ，有24,000行代碼，410個Java文件和10個前綴： Bc ， Cc ， Tk ， Rq ， Rs ， Fb ， Fk ， Hm ， Ps和Xe 。 記住它們的意思并不難，對吧？

在所有240個類中 ，最長的名稱是RqWithDefaultHeader 。

我發現這種用于類命名的方法相當方便。 我在以下開源項目（在GitHub中）中使用了它： yegor256 / takes （10個前綴）， yegor256 / jare （5個前綴）， yegor256 / rultor （6個前綴）和yegor256 / wring （5個前綴）。

您可能還會發現這些有趣的相關文章： 復合名稱是代碼的氣味 ； Java代碼中的典型錯誤 ; 您的對象封裝了多少？ ; 只有一個主要的建設者 ; 為什么InputStream設計錯誤 ;

翻譯自: https://www.javacodegeeks.com/2017/03/handle-problem-many-classes.html

總結

以上是生活随笔為你收集整理的如何处理班级过多的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

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