昨天，我們對於物件導向設計有初步了解後，今天，我們接續來看看物件設計導向的原則。
說到物件導向設計原則，就不得不提 SOLID 以及 DRY 和 LoD 等在軟體界常常被提及的原則和技巧。
由 Robert C. Martin 所提出，在做物件導向開發軟體時若能遵循SOLID原則，將會使應用程式更加有彈性也易於維護。
A class should have only one reason to change.
意味著把職責劃分清楚，降低每個函式的複雜度，每個物件只要單純負責實現某個特定目的即可。
You should be able to extend a classes behavior, without modifying it.
意味著您應該能夠通過擴展現有的程式碼來引入新功能，而無需修改現有的程式碼。這可以通過使用抽象和多型來實現。
Derived classes must be substitutable for their base classes.
當實作繼承時，子類別應該能夠替換其父類別，而不會破壞程式的正確性。換句話說，子類別應該能夠完全取代其父類別，而不會影響程式碼的行為。（對於替換的說明與繼承使用時機，可以看這位大大的文章去加深對於 LSP的理解）
Make fine grained interfaces that are client specific.
不應該要求客戶端依賴於它們不需要使用的介面。這意味著應該將大型介面拆分為更小、更特定的部分，以便客戶端只需實現它們所需的功能。
A. High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces).
高階模組不應該依賴於低階模組，兩者都該依賴抽象。
B. Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
抽象不應該依賴於具體實作方式。具體實作方式則應該依賴抽象。
簡單來說就是高層模組不應該依賴於低層模組，兩者都應該依賴於抽象。這也意味著抽象不應該依賴於具體實現，而具體實現應該依賴於抽象。這有助於實現鬆散耦合，提高程式碼的可測試性和可變性。
不應該在程式碼中重複相同的邏輯、功能或資訊，而是應該將這些內容抽象化、統一化，並通過重用來減少程式碼的冗餘，將常用的邏輯封裝為函數、類別或模組，可以使這些功能在不同的地方重用，提高程式碼的重用性。（相關的應用推薦參考這位大大的文章，裡頭有對於DRY做更詳盡的說明！）
又被稱作 Least Knowledge Principle，其定義為：各單元對其他單元所知應當有限：只瞭解與目前單元最相關之單元一個物件應該作為參數傳遞給方法中的物件或在方法內部創建的物件進行溝通，而不應該與其他物件的內部細節溝通。
這個原則的目的在於降低對其他類別的依賴程度，從而減少系統中的耦合。這樣可以使每個物件的職責更加清晰，並且當其他物件發生變化時，不會影響到不相關的物件。
另外，除了以上提及的設計原則，物件導向設計亦延伸出許多模式，設計模式是程式設計中常見問題的典型解決方案。每個模式就像一張藍圖， 你可以通過對其進行定制來解決程式碼中的特定設計題。由於涵蓋範圍太廣，小妹尚未研究完畢，就不在此作討論，有興趣者可以自行參閱書籍《深入淺出設計模式》或是網站REFACTORING・GURU。
假設有一個基於類別的物件導向語言，資料和行為被結合成單一的物件，物件之間通過訊息傳送來呼叫彼此的行為，每個類別定義了方法和屬性，方法在收到訊息時被呼叫。
字串物件代表字串資料，並且每個字串物件包含自己的資料，物件可以被實例化，每個實例都具有相同的方法和屬性。物件之間的行為相似，但資料不同。這樣的設計避免了對資料和行為進行分裂，而是將它們結合在物件中，增強了封裝性。
物件導向語言特別強調資料和行為的結合、封裝性、類別的定義和開放性。此外，物件導向設計的本身還具有封裝、繼承、多型、抽象這些特性，也會在接下來的章節一一作說明。
參考資料：
iThome鐵人賽
看影片追技術