只有一個功能足夠內聚的類嗎？

Question

在他的崗位SOLID: the next step is Functional，馬克西曼說：

如果繼續行駛你對小接口設計，你最終會在最終作用接口到達：用單一方法的接口[... ]如果你像這樣應用SRP和ISP，你很可能會發展出一個代碼庫，其中包含許多細粒度的類，每個類都有一個方法。這發生在我身上不止一次。

我的擔心是關於這些類的凝聚力。這種方法是否推動到 功能的凝聚力？這些課程是否具有協調性？ 對代碼一致性有不良影響嗎？

Answer 1

有凝聚力的一個偉大的定義，在書中提出Growing object oriented software guided by tests，指出以下：

一個元素的凝聚力是否是自己的責任 形式的意義單位的度量。例如，解析日期爲 和URL的類不是一致的，因爲它們是不相關的概念。想想 洗衣服和洗碗機的機器 - 這不太可能同時兼得 。另一方面，僅解析URL中標點符號 的類不太可能一致，因爲它不代表整個概念。爲了完成任何事情，程序員必須找到 協議，主機，資源等其他解析器。具有 「高」一致性的特點更易於維護。

這可能很快進入主觀領域，但我會爭辯說SRP和凝聚力有時是直接相關和正交概念。如果你只有一種方法的類，那麼肯定的是，它只是一件事情，它是有凝聚力的。而且，你也失去了一些東西，比如說。這個班現在太細緻了，本身就沒用。

在功能風格上，擁有這樣的類很有意義。這完全是關於組合函數來實現結果。 C＃使得這種風格成爲可能，但也非常冗長，所以當你在以這種方式設計代碼庫的情況下，當他爭論F＃時，我完全同意他的看法。

這個好或壞的設計是一個主觀的問題，但我認爲我們可以客觀地說一些事情。一種方法的性質幾乎可以保證尊重SRP（當然，你仍然可以錯過這一點，並用一種​​強大的方法來製作神類）。因此，以這種方式編寫的代碼應該具有我們期望的所有好處，即。鬆散耦合，可組合和可維護。但是關於丟失這樣的代碼的全貌也有些話要說。

我會爭辯說，在大多數情況下，這兩者的組合是必需的，在大多數代碼庫中傾向於使用單一方法的類。例如，您可以將大部分低級別代碼編寫爲具有這些類的可重用的庫集合。一旦你接近API級別，你就可以編寫這樣的類來獲得你想要的邏輯，然後將這些邏輯暴露給你的客戶，使它們成爲更加凝聚力的功能塊。客戶可以享受到更緊密的高級代碼路徑，從而更方便地使用和更好地發現您的庫支持的功能，同時還具有讓您的低級代碼以這種方式編寫的所有好處可以維護和靈活地改變。