架構設計要按照什麼原則進行呢？

一、單一職責原則(Single Responsibility Principle)

說到單一職責原則，很多人都會不屑一顧。稍有經驗的程式設計師即使從來沒有讀過設計模式、從來沒有聽說過單一職責原則，在設計軟體時也會自覺的遵守這一重要原則，因為這是常識。

在軟體程式設計中，誰也不希望因為修改了一個功能導致其他的功能發生故障。而避免出現這一問題的方法便是遵循單一職責原則。

雖然單一職責原則如此簡單，並且被認為是常識，但是即便是經驗豐富的程式設計師寫出的程式，也會有違背這一原則的程式碼存在。

為什麼會出現這種現象呢?因為有職責擴散。所謂職責擴散，就是因為某種原因，職責P被分化為粒度更細的職責P1和P2。

 

單一職責原則的優點有：

可以降低類的複雜度，一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；gendan5.com/af/shangzheng.html

提高類的可讀性，提高系統的可維護性；

變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。

單一職責原則不只是物件導向程式設計思想所特有的，只要是模組化的程式設計，都需要遵循這一重要原則。

 

二、依賴倒轉原則(Dependence Inversion Principle)

高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。

即針對介面程式設計，不要針對實現程式設計，依賴倒轉其實就是誰也不要依靠誰，除了約定的介面，大家都可以靈活自如。

依賴倒轉可以說是物件導向設計的標誌，用哪種語言來編寫程式不重要，如果編寫時考慮的都是如何針對抽象程式設計而不是針對細節程式設計，即程式中所有的依賴關係都是終止於抽象類或者介面，那就是物件導向的設計，反之那就是過程化的設計了。

如果設計的各個部件或類相互依賴，這樣就是耦合度高，難以維護和擴充套件，這也就體現不出物件導向的好處了。

 

三、迪米特法則(Law Of Demeter)

迪米特法則其根本思想，是強調了類之間的松耦合，類之間的耦合越弱,越有利於複用，一個處在弱耦合的類被修改，不會對有關係的類造成影響，也就是說，資訊的隱藏促進了軟體的複用。

自從我們接觸程式設計開始，就知道了軟體程式設計的總的原則：低耦合，高內聚。無論是程式導向程式設計還是物件導向程式設計，只有使各個模組之間的耦合儘量的低，才能提高程式碼的複用率。低耦合的優點不言而喻，但是怎麼樣程式設計才能做到低耦合呢?那正是迪米特法則要去完成的。

迪米特法則又叫最少知道原則，通俗的來講就是一個類對自己依賴的類知道的越少越好。也就是說對於被依賴的類來說，無論邏輯多麼複雜，都儘量地的將邏輯封裝在類的內部，對外除了提供的public方法，不對外洩漏任何資訊。

迪米特法則還有一個更簡單的定義：

只與直接的朋友通訊。首先來解釋一下什麼是直接的朋友：每個物件都會與其他物件有耦合關係，只要兩個物件之間有耦合關係，我們就說這兩個物件之間是朋友關係。

耦合的方式很多，依賴、關聯、組合、聚合等。其中，我們稱出現成員變數、方法引數、方法返回值中的類為直接的朋友，而出現在區域性變數中的類則不是直接的朋友。也就是說，陌生的類最好不要作為區域性變數的形式出現在類的內部。