我雖然自問不怎麼時尚，但多少也聽過時尚圈流行混搭 (mashup)，尤其是服裝的穿著，走在都會的街上想不碰到混搭穿著的人還蠻難的，這樣的穿法是時尚的表現，但是如果系統架構也這樣，可就一點也不時尚，反而會埋下很多的地雷給自己踩 ...
我雖然自問不怎麼時尚，但多少也聽過時尚圈流行混搭 (mashup)，尤其是服裝的穿著，走在都會的街上想不碰到混搭穿著的人還蠻難的，這樣的穿法是時尚的表現，但是如果系統架構也這樣，可就一點也不時尚，反而會埋下很多的地雷給自己踩 ...
物件導向的系統分析法以及之前我在文章中提到的 "單一職責原則 (single responsibility principle)" 不是隨便說說的，單一職責原則讓程式碼之間沒有強烈的耦合性，讓它便於切割與組裝，而單一職責原則的前提是，在設計時就要職責分明，簡單的說，就是 "該做什麼就做什麼，不需要額外的東西"，以 MVC 架構來說，M 是負責 Model，V 是負責資料呈現與使用者介面，而 C 是協調與控制 M 和 V 的整合工作。一個具有 MVC 架構的程式，它們的 M/V/C 都是職責獨立，並不相互依賴彼此。
然而事與願違，更多的專案內，程式碼之間 (或與資料之間) 的耦合性異常嚴重，V 要和 M 相依，而 M 要存放 V 要呈現出來的結果資料，V 又做了太多的 C (ASP.NET Web Form 的 event model 就是如此)，C 又需要靠 M 才能完整的執行動作 ... 這些都是因為耦合性太嚴重所導致的現象。職責不明的程式碼很容易就牽一髮動全身，改了一個小地方會讓整個系統崩潰，而如果資料沒有依照 V 的規格來存，那 V 就一定會呈現不對的資料 (例如 Y/N，用一個 bit 就可以存，但就有人愛用 varchar(3) 或 varchar(1)，把資料庫當 V 來用了)。這種系統我也看了不少，若是初學者寫出這樣的系統還可以來的及試著導正觀念，但若是出自一個已工作數年的開發人員手裡，那 ... 自求多褔可能比較好。
因此，在系統架構上應用單一職責原則以及職責分離的思維來設計，在無形中能強化整個系統的體質，並且讓系統具有物件導向的高彈性，也不會再出現牽一髮動全身的風險，明確的將各個模組的職責都切開，也有助於日後的維護工作，再結合單元測試與整合測試，那麼整個系統的服務品質 (service quailfy) 會提升很多。如果是公司的舊系統，也許當下無法改變，但改變是一滴一滴累積的，可以先從小型的新專案開始做，然後慢慢的將影響力擴大，當公司想要更新系統或計畫新的系統時，就可以將這個思維注入。
若覺得程式碼的職責切分一時不習慣，可以先以資料和程式間的職責切分開始，資料應該就只是資料，而不是呈現用的資料，將資料變成報表或網頁上看到的內容，是 V 的職責，資料庫要做的就只是讓 V/C 來快速存取資料而已，其他的就不是資料庫該做的。而其他 M/V/C 之間的互動也是類似的觀念。
記住，適當的職責切割有助於系統品質提升，而不當的混搭只會挖洞給自己跳而已。
