昨天跟大家講解了物件導向的基本特性，為了讓後面講解的Spring Boot可以更好上手，今天接著說明軟體設計的概念

軟體設計的目的

實務上接收到需求時，首要任務是先與需求方釐清需求，接著繪製相關流程圖或類圖，目的是讓程式碼實作過程有更明確的目的，在銜接昨日說明的物件導向概念，在繪製類圖的步驟，可以將需求轉化為撰寫業務邏輯所需的類別實體，進而用更具體的方式呈現模組間的依賴關係，同時進行設計的過程能確保團隊執行的共識，使專案開發有更高的效率

SOLID原則

說到軟體設計不得不提開發通用準則SOLID，這個原則存在的目的，就是為了開發出更有彈性、好抽換的軟體架構，實務上常見的設計模式就是參考SOLID原則，實作的軟體架構，可以用來應對開發常見情境，使程式達到好維護、可複用的目的

單一職責原則(SRP)
單一職責原則是在強調程式碼的內聚力，定義是說一個方法或類別的改動，只能因為一個原因，這裡要注意軟體架構中的「原因」，這裡要注意「需求改動不能成為改變的理由」，比較偏向單一個步驟要完成的核心目的(職責)，因此實際的做法為需求改動時，必須先釐清一系列的執行流程中的哪些步驟，彼此的依賴關係，主要調整負責這次改動業務的模組即可

開放封閉原則(OCP)
你可曾想過在不更改現有程式碼的狀況下，完成新的需求?開放封閉原則的核心精神，就是為了實踐這個目的而存在的理論，實際作法在從外面修改內部程式碼的實作邏輯，可以善用泛型、抽象介面或改變方法參數來達成，重點在於「擴展」現有架構來實現新需求，也因為這個作法強調了程式碼的複用性，能有效降低專案維護成本

里氏替換原則(LSP)
這個原則的定義為「基礎類別的更動，不應該影響到子類別」，改動子類別繼承的基礎類別時，不應該影響到系統運作，若要完美詮釋這個特性，必須將重點放在「繼承的職責」，可以將這段話理解成，由於子類別承襲了父類別的特性，只要父類別出現的地方，都可以用子類別實現替換

介面隔離原則(ISP)
程式設計中的介面，可以想像成是比職責更抽象的業務(多個步驟)，為了實現邏輯抽換與規範特定業務執行的行為，會透過定義介面(Interface)來要求類別必須實作某些方法，在強制約束的狀況下多少會出現，不屬於我的業務範疇，但我必須做的問題存在，為了讓介面要求的步驟能更清晰，這時候必須將不屬於類別應盡職責的方法，從介面中抽離，並定義到其他介面中實現隔離

依賴反轉原則(DIP)
這個原則可以用兩個單詞解釋，第一個詞「依賴」是指一個類別的屬性或方法參數，必須引用某個具體實例，此時擁有屬性的類別稱為「高階模組」，屬性參考的具體實例稱為「低階模組」，由於高階模組需要使用到低階模組，此時兩者之間產生了依賴關係，這時候有個問題，當需求改動時需要手動修改依賴的低階模組，違反了開放封閉原則；為了改善這個問題，因此產生了反轉的實作概念，強調了將模組抽象化，高階模組不在需要直接使用具體實例，改由外部注入修改依賴的低階元件實例