我基本上想知道在實際代碼中使用單一責任原則合理的人數百分比和實際上有多少人。在Podcast #38喬爾談論這個OOP原理是多麼無用的現實世界;並進一步說明，這表明像鮑勃叔叔這樣的人可能不會寫非平凡的系統。在「現實世界」中使用單一責任原則
我個人編寫或在一些軟件項目中發揮了重要作用，但在我年輕的職業生涯中只有現在纔會遇到這種模式。我喜歡這個原則的聲音，並且真的很想開始使用它。我發現喬爾在播客中的論點相當薄弱（如果你繼續閱讀博客評論here）。但是，它裏面有沒有道理？
社區有什麼想法？
我已經有一些應用SOLID原理的經驗，我的經驗一直很好。我也聽到了播客，聽起來好像傑夫和喬爾都沒有嘗試過他們談論的任何事情都足以真正評估好處。反對的主要觀點通常是「你寫更多的代碼」。如果我看看我做了什麼，我會寫10或許多20％的代碼（通常是接口定義），但是因爲所有東西都是高度分離的，所以它更易於維護。我幾乎沒有遇到過我的應用程序的某個部分發生變化而導致其他部分崩潰的情況所以我必須維護20％的額外代碼才能爲自己付出代價。
傑夫也錯過了代碼質量的觀點。他並不認爲代碼質量對於客戶來說是一大好處。而他是對的，顧客不在乎。客戶確實很在意快速實施新功能，這就是代碼質量的問題。我發現保持代碼質量儘可能高的投資始終在幾個月內得到回報。高品質=低維護。
我同意他們，就像任何事情你必須務實這些事情。如果你需要提供一些東西，然後繼續做，快速和骯髒。但之後清理。
我還沒有閱讀或聽取喬爾的評論，所以不能評論這些具體。
我認爲你必須從目標的角度來看待單一職責原則，而不是嚴格的要求。與軟件開發中的許多事情一樣，有些理想應該爭取，但除非您的代碼沒有貨幣收益或成本，否則您必須務實地滿足客戶的需求。
實際上，在面向對象的情況下很難獲得真正的SRP。考慮一個存在於複雜系統中的類。它可能只有一個面向業務的職責（例如打印報告），但是它在內部還有很多違反純粹SRP理想的其他責任，例如日誌記錄和異常處理。如果您顯着改變日誌記錄機制，則可能需要更改打印類所做的調用。
這就是爲什麼AOP被構思出來的原因。使用它你不需要改變任何東西，除了日誌類來改變日誌記錄。
由於顯而易見的原因，努力爭取面向業務的SRP是一件好事，但對於足夠複雜的系統，您永遠不會在OOP中獲得真正的SRP。 AOP，當然，但不是面向對象。
我不知道這是喬爾的推理是什麼，但這就是我將如何處理這個想法。
一般來說，我同意SOLID原則，但您也必須將其納入上下文中。如果你正在寫一個概念證明，那麼SOLID原則就不太適用。
另一方面，如果您正在開發的產品壽命將跨越多年，那麼您最好仔細查看SOLID原則並應用它們。否則，公司將耗費巨大的生產力。
關於喬爾和他的評論，他有一個有效的觀點。有時產品需要運送或公司失敗。就是那樣子。
作爲一名開發人員，您的工作是運送產品，但僅僅因爲時間緊迫並不意味着您會遇到糟糕的架構。像使用數據集或業務實體這樣的選擇是一個簡單的決策，兩者都有類似的實施工作，但從長遠來看，兩者之間的新功能開發和維護非常激烈。
我正在開發一個項目，該項目在一個應該可以被其他人輕鬆擴展的框架中完成許多不同的，可怕的複雜事情。
起初，類很大，做了很多事情。爲了改變這些行爲，你必須擴展這些類。這些方法都是虛擬的，並沒有改變對象的狀態，因此很容易做到這一點。
但是隨着系統的發展，它變得更加清晰，框架最終會出現一系列單一的對象，每個對象都有looooong繼承鏈。這也導致了意想不到的依賴關係 - 一個抽象方法將X類的集合產生一個在基類中定義的對象Y，這意味着EVERYBODY必須這樣做，即使它對繼承樹的一半沒有意義。這也導致需要進行數十次單元測試的大規模類才能使代碼覆蓋率超過80％，並且複雜性使得您不確定是否正確覆蓋了所有內容。很顯然，這種設計會導致框架非常僵硬和僵化。
所以我們重新設計了一切沿SRP線。你需要有你的接口，基類以及可能的一個或多個實現類。每一個都是由不同對象組成的組成的，它們執行整個過程的關鍵功能。如果你想改變一個部分，你沒有重寫一個方法，你會產生另一個對象來擴展必需的接口/基類並以不同的方式執行它的工作。 SRP甚至被納入了類方法的參數和返回值。對於那些需要靈活的系統部分，不是傳遞用於生成Y對象的X類集合，而是創建一個類來封裝Y對象生產過程。然後，系統中的組件將傳遞給這些生產者，將他們與其他人（生產者的責任）結合起來，最終用它們來生產Y.這允許創建不同類型的生產者，所有這些都可以被精確處理同樣，即使他們做了大不相同的事情。此舉也極大地降低了每個班級的代碼庫，並使他們更容易測試。
我想說，作爲一名新開發人員，將所有事情都打破到這個級別是非常困難的。你幾乎不得不寫一大塊泥土，理解它是如何工作的，然後將它重新設計成幾個不同的組件，每個組件都負責整體的一部分。
我認爲應該可以爲所有類寫一個簡單的單行主要責任。在這一行中，「和」一詞通常不是一個好兆頭。單一責任往往歸結爲選擇適當的抽象。
類附近的圖形用戶界面傾向於反映圖形用戶界面，並具有「作爲XXXX的GUI」的單一職責。懦夫的解決方案..
我認爲做一名有紀律的OO開發人員並儘可能遵守SRP的最大好處是易於測試和維護，所以我會說SRP是任何將要測試/維護的系統的一個好目標（基本上，除了一次性系統以外的任何東西）。
大量編程理論中存在的最大問題是，它們專注於提示代碼中的良好屬性實際上是代碼的良好屬性。他們是對的，因爲他們本質上是正確的，因此不是特別有用。
是的，代碼應該寫得很好，是的，事情不應該重複，並且是的，變化不應該在意想不到的地方造成奇怪的休息。但是，在一天結束的時候，真正簡單，真正一致的代碼以簡單易懂的方式表達解決方案的價值遠遠大於滿足一些嚴格原則的大型複雜系統。作爲一個行業，我們傾向於採取很好的想法，在尋求「正確」解決方案時造成大量不必要的複雜性，而不是最好的解決方案。
Paul。
我認爲固體原理有時不符合設計類時通常應用的自然/商業邏輯。 Robert C. Martin提出了一個Rectange和Square類的例子（Square不應該是Rectangle的後代）。
http://www.hanselminutes.com/default.aspx?showID=163
我不知道它是關於SRP但這個想法是一樣的。固體原則可能導致違反直覺的決定，並且很難通過這個障礙。
對我來說，「指導方針」比「原則」更合適。
我想你應該把它變成一個維基，因爲沒有一個明確的答案。 – Will 2009-01-28 18:42:49
我不確定我是否同意。我認爲他們是更不正確的答案。我認爲太多人認爲這比實際情況更主觀或者更敏感 - 這也是我發佈這個問題的部分原因。儘管感謝您的評論。 – Thiru 2009-01-29 17:08:39