關于面向對象的原則,相信大家都很清楚.但真正使用時,我想我們都會違反一些原則,因為要遵守這些原則,我們必須要多寫好多代碼.最后得不嘗試. 下面我就關于這些原則發表一下個人的看法:

一、單一職責原則 ?? 就一個類而言，應該僅有一個引起它變化的原因。軟件設計真正要做的許多內容，就是發現職責并把那些職責相互分離。測試驅動的開發實踐常常會在設計出現臭味之前就迫使我們分離職責。?
??這個很重要 ,我在程序開發中都會遵守這個原則.

二、“開一閉”原則講的是：一個軟件實體應當對擴展開放，對修改關閉。 這個規則說的是，在設計一個模塊的時候，應當使這個模塊可以在不被修改的前提下被擴展。 從另外一個角度講，就是所謂的“對可變性封裝原則”。“對可變性封裝原則”意味著兩點： 1 .一種可變性不應當散落在代碼的很多角落里，而應當被封裝到一個對象里面。同一種可變性的不同表象意味著同一個繼承等級結構中的具體子類。 2.一種可變性不應當與另一種可變性混合在一起。即類圖的繼承結構一般不應超過兩層。 做到“開—閉”原則不是一件容易的事，但是也有很多規律可循，這些規律同樣也是設計原則，它們是實現開—閉原則的工具。?
???這個也比較重要,但現實中也是比較難實現,經常由于業務規則變了,我們不得不更改我們的類.除非一些我們可預見的,比如緩存,我們有多種實現的方式,所以通過定義接口的方式.如果我們要換一種緩存方案,我們只要換一個實現類就行了.

三、里氏代換原則： 如果對每一個類型為T1的對象o1,都有類型為T2的對象o2，使得以T1定義的所有程序P在所有對象o1都換成o2時，程序P的行為沒有變化，那么類型T2是T1的子類型。 即如果一個軟件實體使用的是基類的話那么也一定適用于子類。但反過來的代換不成立。 如果有兩個具體類A和B之間的關系違反了里氏代換原則，可以在以下兩種重構方案中選擇一種： 1 .創建一個新的抽象類C,作為兩個具體類的超類，將A和B共同的行為移動到C中，從而解決A和B行為不完全一致的問題。 2 .從B到A的繼承關系改寫為委派關系。 ??
????這個我們也經常用到,我們經常會把一些類共同的東西,抽象到基類里去實現,比如增加,刪除,修改,查詢等.同時我們也會用一些vitual函數,和override去重寫一些基類行為.

四、依賴倒置原則 依賴倒置原則講的是：要依賴于抽象，不要依賴于具體。即針對接口編程，不要針對實現編程。針對接口編程的意思是，應當使用接口和抽象類進行變量的類型聲明、參量的類型聲明，方法的返還類型聲明，以及數據類型的轉換等。不要針對實現編程的意思就是說，不應當使用具體類進行變量的類型聲明、參量的類型聲明，方法的返還類型聲明，以及數據類型的轉換等。 依賴倒置原則雖然強大，但卻不易實現，因為依賴倒置的緣故，對象的創建很可能要使用對象工廠，以避免對具體類的直接引用，此原則的使用還會導致大量的類。維護這樣的系統需要較好的面向對象的設計知識。 此外，依賴倒置原則假定所有的具體類都是變化的，這也不總是正確的。有一些具體類可能是相當穩定、不會發生變化的，消費這個具體類實例的客戶端完全可以依賴于這個具體類。?
???這個東西我們就會經常違反的.比如我們的三層架構,我相信很多人都是直接new一個對象去操作的.如果那么多表,我們都是針對接口編程,我們會發現這些東西其實用處不大.因為我們大部分項目的dal層,bll層是不變的.其實我也用過一個框架,那里就是所有的dal,bll層都基于IOC編程的.結果我發現,用起來真的很麻煩的. 我們想增加一個方法要在4個地方寫函數. 而且想用F12跟進去查看代碼,是跟不進去的.只能跟到接口那里.? 最要命的就是它那個報錯.經常會報配置錯誤,其實一查根本不是配置錯誤.只是生成的類有問題

五、接口隔離原則 接口隔離原則講的是：使用多個專門的接口比使用單一的接口要好。從客戶的角度來說：一個類對另外一個類的依賴性應當是建立在最小的接口上的。如果客戶端只需要某一些方法的話，那么就應當向客戶端提供這些需要的方法，而不要提供不需要的方法。提供接口意味著向客戶端作出承諾，過多的承諾會給系統的維護造成不必要的負擔。?
? 這個也是我們要去遵守的.

六、合成、聚合復用原則 合成、聚合復用原則就是在一個新的對象里面使用一些已有的對象，使之成為新對象的一部份，新的對象通過向這些對象的委派達到復用已有功能的目的。這個原則有一個簡短的描述：要盡量使用合成、聚合，盡量不要使用繼承。合成、聚合有如下好處： 新對象存取成分對象的唯一方法是通過成分對象的接口。 這種復用是黑箱復用，因為成分對象的內部細節是新對象所看不到的。 這種復用可以在運行時間內動態進行，新對象可以動態的引用與成分對象類型相同的對象。 合成、聚合可以應用到任何環境中去，而繼承只能應用到一些有限環境中去。 導致錯誤的使用合成、聚合與繼承的一個常見原因是錯誤的把“Has-a”關系當作“Is-a”關系。如果兩個類是“Has-a”關系那么應使用合成、聚合，如果是“Is-a”關系那么可使用繼承。?
??這也是我們經常用到的.

七、迪米特法則 迪米特法則說的是一個對象應該對其它對象有盡可能少的了解。即只與你直接的朋友通信，不要跟陌生人說話。如果需要和陌生人通話，而你的朋友與陌生人是朋友，那么可以將你對陌生人的調用由你的朋友轉發，使得某人只知道朋友，不知道陌生人。換言之，某人會認為他所調用的是朋友的方法。 以下條件稱為朋友的條件： 當前對象本身。 以參量的形式傳入到當前對象方法中的對象。 當前對象的實例變量直接引用的對象。 當前對象的實例變量如果是一個聚集，那么聚集中的元素也都是朋友。 當前對象所創建的對象。 任何一個對象，如果滿足上面的條件之一，就是當前對象的朋友，否則就是陌生人。 迪米特法則的主要用意是控制信息的過載，在將其運用到系統設計中應注意以下幾點： 在類的劃分上，應當創建有弱耦合的類。類之間的耦合越弱，就越有利于復用。 在類的結構設計上，每一個類都應當盡量降低成員的訪問權限。一個類不應當public自己的屬性，而應當提供取值和賦值的方法讓外界間接訪問自己的屬性。 在類的設計上，只要有可能，一個類應當設計成 在對其它對象的引用上，一個類對其它對象的引用應該降到最低。?
? ??這個也是我們要去遵守的.

上面是在對oop使用原則的理解,不知道大家是如何理解的.

總結

以上是生活随笔為你收集整理的关于面向对象的的设计原则的使用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。