設計模式之單一職責原則學習

單一職責原則：就乙個類而言應該僅有乙個引起它變化的原因。

比如寫乙個視窗應用程式。我們會建立乙個類，將各種各樣的**，如某種演算法的**或是訪問資料庫的**，都放在這個類中。以後一旦需求有所更改就必須修改這個類。各個功能的耦合性太大，牽一髮而動全身。維護很麻煩，復用不可能，也缺乏靈活性。由於c

語言是我的第一門程式語言，這麼多年的使用，面向過程的思想早已根深蒂固。短時間很難培養起使用物件導向開發的習慣。看來任何東西都有兩面性，在學

c++之前先學習

c語言可能對入門有幫助，但也有一些弊端。世上很多東西都是矛盾的，重要的是要從這些矛盾中找到乙個平衡點。

如果乙個類承擔的功能過多，就等於把這些職責偶合在一起，乙個職責的變化可能會削弱或抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭到意想不到的破壞。

俄羅斯方塊遊戲的設計

應該考慮將程式至少分為兩個類：乙個是視窗類，用於處理介面互動。另乙個是遊戲邏輯類。當有一天要改變介面或是移植到其他平台上就不涉及遊戲邏輯的改變。

對於遊戲邏輯設計，方塊的可移動區域，可以用乙個二維陣列進行表示。對方塊的各種操作就是對二維陣列值進行的操作。

。我覺得也需要兩個大類，首先是各種圖形的表示類，比如口型，l型，1型。給出它的各個成員在二維陣列的座標。它們應該從乙個共同的基類繼承。另外乙個是對圖形類進行操作的操作類。比如左移、右移、變形以及碰撞檢測、消行等。可以考慮使用策略模式來對各個圖形類進行管理。

**稍後奉上。。。。。

軟體設計真正要做的內容，就是發現職責並把那些指職責分離。如果能找出多於乙個動機去改變乙個類，這個類就具有多個職責，此時就應該考慮職責分離。