乙個產品簡單一些，職責單一一些，或許是更好的選擇。
乙個類而言，應該僅有乙個引起它變化的原因。打個比方，我們在新建乙個winform應用程式的時候，就會有個form類自動生成，那麼，在這個自動生成的類裡面，我們不能把所有的**都往裡面填，什麼db連線，邏輯層的**等等都往裡面塞。萬一哪天要改個需求，你就得去改這個form類裡面的內容。麻煩啊！！！
如果乙個類承擔的指責過多，就等於把這些指責耦合在一起了，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。其實就是要讓我們搞清楚哪些是ui的，哪些是邏輯的，哪些是持久層的之類的進行分離。不要揉在一起！
職責分離才能把事情辦得更好。**會變得易維護、易擴充套件、易復用。
設計模式之單一職責原則學習
單一職責原則 就乙個類而言應該僅有乙個引起它變化的原因。比如寫乙個視窗應用程式。我們會建立乙個類，將各種各樣的 如某種演算法的 或是訪問資料庫的 都放在這個類中。以後一旦需求有所更改就必須修改這個類。各個功能的耦合性太大，牽一髮而動全身。維護很麻煩，復用不可能，也缺乏靈活性。由於c 語言是我的第一門...
設計模式之單一職責原則
關於單一職責原則，我想大家都聽過不少，今天來看看這個原則具體是什麼，有哪些好處使我們需要選擇遵守它呢？一 定義 乙個類只能因為乙個原因而修改。怎麼理解呢？簡單來說，乙個類只能實現一項功能，或者換句話說，乙個類只有乙個職責，只有當這個職責發生變化，它才會被修改，說白了就是乙個類質感乙個類該幹的事。二 ...
設計模式之單一職責原則
首先就名字而言不難想象，單一必定是只能有乙個，而這個乙個指的是什麼呢，那就是乙個職責。而職責通俗易懂來說就是乙個功能，乙個類只能有乙個功能，而如果有兩個及以上的功能就不再符合單一職責原則了。就好比乙個水壺，它的功能就只是裝水，而不存放別的東西，那它就滿足了單一職責原則。優點有複雜度低，或者說簡單明瞭...