brannon b. king是供職於autonomous solution inc.的一名軟體工程師，他在msdn雜誌
2023年05月刊發表了一篇題為《違背c#中solid原則的危險》的文章。作者指出了研發人員在c#編碼中可能出現的一些常見錯誤，違背solid原則將導致**不易擴充套件、難以維護。
\u0026#xd;\n
king提供了計數器的示例**，並針對solid每條原則給出了建議，但為了簡潔起見我們只節選了開閉原則（ocp）相關的一些內容。開閉原則（ocp）規定「軟體實體（類、模組、函式等）應該對擴充套件開放，對修改關閉」。根據king的說法，下面這段**違背了開閉原則
\u0026#xd;\n
\u0026#xd;\nvoid drawnerd(nerd nerd)\u0026#xd;\n
因為你需要在客戶每次需要顯示新增內容時修改此方法，而且，客戶始終需要顯示新增內容。建議將繪製替換成通用程式：
\u0026#xd;\n
\u0026#xd;\nreadonly ilist\u0026lt;irenderer\u0026gt; _renderers = new list\u0026lt;irenderer\u0026gt;();\u0026#xd;\nvoid draw(nerd nerd) \u0026#xd;\n\u0026#xd;\n
思路是這樣的：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n…編寫實現已知介面的繪製類（或有關繪製類的類）。呈現器必須能夠決定其是否可以或應該基於輸入內容繪製任何內容。例如，帶式繪製**可以移動到其自身的「帶式呈現器」，用於檢查介面並視需要繼續執行。
\u0026#xd;\n
基類引用繼承類是違背開閉原則的另乙個例子
\u0026#xd;\n
\u0026#xd;\nclass nerd \u0026#xd;\n}\u0026#xd;\nclass childofnerd : nerd\u0026#xd;\n
作者建議「基類絕不能直接引用其繼承類。」。
\u0026#xd;\n
對等類中也可能存在該問題：
\u0026#xd;\n
\u0026#xd;\nclass nerdsinanarc \u0026#xd;\n ...\u0026#xd;\n}\u0026#xd;\n
king解釋道：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n通常情況下，物件層次結構中的弧線和直線是對等的。它們不應該知道彼此之間的非繼承的詳盡細節，因為這些細節通常是最優交叉演算法所需的。隨時修改其中乙個，而無需更改另乙個。這再一次違背了單一責任。儲存弧線，還是分析這些弧線？將分析操作置於其自己的實用程式類中。
\u0026#xd;\n
儘管對於小型專案來說可能不是很必要，但為了避免產生麵條式**，**規模越大，嚴格執行solid原則的重要性就越明顯。
\u0026#xd;\n
程式設計的SOLID原則
要想設計乙個良好的程式，建議採用solid原則，若考慮了solid，可以使程式在模組內具有高內聚 而模組間具有低耦合的特點。其中solid原則包括5方面的內容 1 通過增加 來擴充套件功能，而不是修改已經存在的 2 若客戶模組和服務模組遵循同乙個介面來設計，則客戶模組可以不關心服務模組的型別，服務模...
類的設計SOLID原則
簡要的記錄一下類的設計原則,乙個良好的類結構設計會對 整潔產生相當重要的影響，雖然不提倡過度設計，但一些簡單而實用的原則還是需要像對待法律一樣去嚴格遵守。觸犯這些原則，總能給我們帶來意想不到的麻煩。1 單一職責 single responsible principle 對於乙個類，應該僅有乙個引起它...
軟體構造的SOLID原則
經典的例子 正方形不是長方形的子類。因為正方形多了乙個長寬相等的屬性。如果長方形的長與寬是可變的，而此時卻用正方形代替了長方形，因為正方形時刻要求長寬相同，所以長寬會同時發生變化，而與我們預期不符，違反了liskov原則。因此二者沒有子類父類的關係。不強迫客戶端依賴於不需要的介面，避免介面汙染和胖介...