如何區分代碼質量的好壞？
要評判好壞，我們是不是需要有一種標準？
相信大家都聽說過“高內聚，低耦合”，即類的內聚性是不是很高，耦合度是不是很低。這一原則可以作爲我們評判軟件設計的好壞。
通俗的說，我們就需要儘量讓寫出的程序易於維護，減少程序與程序之間的複雜性、耦合度。其目的就是爲了讓對象A和其依賴的其他對象解耦，減少二者的依賴。即通過“注入”的方式去解決依賴問題。
下面介紹一些軟件設計的思想以及面向對象設計的原則。在日常開發中，如果對這些知識能夠熟練掌握並且靈活運用，就能寫出更優質的代碼。
一、軟件設計思想
1. 控制反轉( Inversion of Control，簡稱 IOC)
從字面上可以理解爲對xx的控制進行了一個反轉，換句話說就是對xx的控制的另一種實現，是一種思路，一種邏輯思想。這個很容易理解。
既然是一種思路，那總有一種解決方案可以實現吧。這就是我們接下來要介紹的依賴注入。
2. 依賴注入(Dependency Injection，簡稱 DI)
依賴注入是 IOC 的一種典型實現。簡單的說，依賴注入就是把對象A所依賴的其他對象B呀C呀的，以屬性或者構造函數的方式傳遞到對象A的內部，而不是直接在對象A內實例化。
其目的就是爲了讓對象A和其依賴的其他對象解耦，減少二者的依賴。即通過“注入”的方式去解決依賴問題。
二、面向對象的五個基本原則（SOLID）
1. 單一職責原則（Single Responsibility Principle，SRP）
定義：一個類應該只有一個引起變化的原因
換句話說，一個類應該只有一個責任。這有助於降低類的複雜性，並使其更容易理解和維護。
2. 開閉原則（Open/Closed Principle，OCP）
定義：要求軟件實體（類、模塊、函數等）應該對擴展是開放的，但對修改是封閉的。這意味着在添加新功能時，不應該修改現有代碼，而是通過擴展現有代碼來實現。
分析：子類擁有父類所有非 private 的行爲和屬性，正因爲有了里氏替換原則，使得繼承複用成爲了可能，只有當子類可以替換掉父類，軟件單位的功能不受到影響時，父類才能真正被複用，而子類也能夠在父類的基礎上增加新的行爲。正是由於子類的可替換性才使得父類類型的模塊在無需修改的情況下就可以擴展。
一個類不應該被強迫實現它不使用的接口。這意味着一個類應該只實現它需要的接口，而不是實現一些不相關的接口。
5. 依賴倒置原則（Dependency Inversion Principle，DIP）
定義：高層模塊不應該依賴於低層模塊，兩者都應該依賴於抽象。同時，抽象不應該依賴於具體實現，具體實現應該依賴於抽象。這有助於減少系統的耦合度。
理解：
1）高層模塊不應該依賴於底層模塊，兩者都應該依賴於抽象。
說明： 這意味着高層模塊（上層代碼）和底層模塊（下層代碼）都應該依賴於共同的抽象接口而不是具體的實現細節。通過共享抽象，可以確保高層和底層之間的松耦合，使系統更加靈活和可擴展。
2）抽象不應該依賴於具體，具體應該依賴於抽象。
說明： 這一點強調的是抽象接口應該是穩定的，而具體的實現可以根據需要進行變化。具體的實現應該遵循抽象定義的接口，而不是反過來。這保證了系統的穩定性和可維護性。
在傳統軟件設計中，高層代碼依賴於下層代碼，當低層出現變動時， 高層代碼也要相應變化，維護成本較高。
DIP的的核心思想是高層定義接口，低層實現這個接口， 從而使得低層依賴於高層，實現模塊之間的松耦合，提高系統的可維護性、可擴展性和可複用性。通過引入抽象層，高層模塊不需要關心底層模塊的具體實現細節，只需要依賴於抽象接口。這樣，當底層模塊發生變化時，高層模塊不受影響，只需要保持對抽象的依賴關係。
三、其他面向對象設計的原則
1. 迪米特原則（Law of Demeter，也叫最少知道原則）
定義： 如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用
分析：迪米特法則強調了類之間的松耦合。類之間的耦合越弱，越有利於複用，一個處在弱耦合的類被修改，不會對有關係的類造成波及。
參考鏈接：http://www.manks.top/yii2-analysis-dependency-injection-principle-inversion-of-control.html