SOLID原則中的SRP是否導致了千篇一律的代碼？

Question

憑藉雄厚的原則尤其是SRP，我們有這麼很多類..
我的意思是，它就像你想建立一個數據庫類
然後，你有
數據庫處理器類處理數據庫（SELECT，INSERT，更新，刪除等），

DatabaseAdapter類，它是一個擴展的PDO類（可以在構造中設置優先默認模式，直接準備語句的新準備方法，將其與param綁定並執行它，

QueryBuilder類，它是SelectStatementBuilder類的父級，InsertStatementBuilder類，DeleteStatementBuilde R類別，UpdateStatementBuilder類（打造的SQLStatement），

表達類積聚在需要表達WHERE子句

的SQLStatement類（其作用就像一個正常的字符串，但它的接口被SQLStatementInterface這樣我們就可以知道，這是一個SQL聲明等。

而且，我知道如果我深入挖掘並再次重構，會有更多的類。

SRP的原理實現是否導致了千篇一律的代碼？ 千層麪代碼是否正常？

Answer 1

一般來說，SRP是一個設計原則，要求您考慮系統的不同責任（也就是改變AKA的原因）。其目標是幫助提高系統的凝聚力。換句話說，一起變化的東西，呆在一起。

Uncle Bob defined SRP爲：

類應該只有一個理由去改變。

當在錯誤的粒度級別上採取SRP可以被解釋爲一個類應該只做一個非常小，低級別的事情，導致過度抽象，沒有明確的好處。通過閱讀他的論文，您會注意到「改變的原因」是在用戶/客戶/消費者需求級別定義的。一個簡單的例子是，如果UI需求的變化導致我改變一個包含一些數據訪問層代碼的類，那麼這個類有不止一個改變的理由（即UI和數據訪問），這違反了SRP。

就你而言，除非你正在構建一個數據庫管理工具，否則沒有理由將原始數據庫類拆分成許多較小的類。如果這是一個典型的（web）應用程序，那麼如果你想改變底層的數據庫實現（比如在測試期間從MySQL到內存數據庫），那麼所有這些類都必須被替換。不妨將它保持簡單。