在前面的五篇文章當中，我們提到了 SOLID 設計原則，分別為

• 單一功能原則 Single Responsibility Principle
• 開放封閉原則 Open-Closed Principle
• 依賴反轉原則 Dependency Inversion Principle
• 里氏替換原則 Liskov Substitution Principle
• 介面隔離原則 Interface Segregation Principles

同樣讓我嘗試用一段話來整理這些內容之間的關係：

如果以公司部門的角度出發，「單一功能原則」確保這個部門只會對應、負責一種業務需求，也就是說，當某種業務有新的需求或舊有需求變化的時候，公司可以很明確知道找哪個部門負責，在這樣的情況下，只要請該部門開始變動，而不會影響其他部門的運作，確保公司的穩定性。

「開放封閉原則」提到，當負責的部門因應新的需求時，可以快速透過「擴展」的方式來加入、整合新的資源（譬如外包廠商）來產生新的功能，而不用大幅度的更動原部門的架構（開放擴展、封閉修改）。

「依賴反轉原則」提到，當負責的部門開始依賴其他資源的時候，譬如外包廠商，需要訂定好「互動規則」，以避免外包廠商變動的時候（譬如更新實作方式、更新產出規格等）時，負責的部門也需要跟著變動。

「里氏替換原則」提到，從客戶的角度來看，今天不管這間公司的部門做了什麼樣的變動、更新，都需要提供同樣的服務給客戶，以避免有錯誤的期待或操作。

最後，「介面隔離原則」提到，從客戶的角度來看，公司部門不應該提供多餘的服務或功能給客戶，以避免當這些服務或功能的改變，造成客戶產生不必要的錯誤。

下一步？

以上的五點，確保了程式碼在面對需求變動時的擴展性、維護性、穩定性。不過這些最終都只是「原則」。在因應不同變化的時，為了要滿足這些原則，就會產生出不同的解決方案。而這些解決方案，就是我們之後要提到的「設計模式」。

什麼是設計模式

設計模式就是人們根據一些常見的問題，整理出來的「解決方案」。這些解決方案其實也只是一張藍圖，實際的執行方式與內容，還是得看不同問題的細節，以及使用的程式語言為何。

所以接下來提到不同的設計模式，每一個模式都有他各自要解決的問題，而設計模式也不是萬能，有其使用的範圍與侷限性。但如果能夠認識一些常見的設計模式，未來在面對問題的時候，就會有更多的藍圖可以參考使用囉。

設計模式的類別

設計模式主要分成三大類，分別是

• Creational Patterns: 關注於如何「創造」新的物件，如何重複使用已有的程式，提高面對需求變動時的彈性
• Structural Patterns: 關注於如何「組合」物件，成為一個新的、更大的物件，然後能夠面對各種不同的需求
• Behaviroral Patters: 關注於物件之間如何「溝通」，讓物件彼此之間能夠更有效的完成任務

在接下來的日子當中，會陸續開始介紹不同的設計模式，也許不會把 GoF 提出的 23 種全部講完，但希望能夠在過程中更了解不同的設計模式在處理的問題，以及如何解決問題