C#面向對象設計的七年夜准繩。本站提示廣大學習愛好者：（C#面向對象設計的七年夜准繩）文章只能為提供參考，不一定能成為您想要的結果。以下是C#面向對象設計的七年夜准繩正文
本文我們要談的七年夜准繩，即：單一職責，裡氏調換，迪米特軌則，依附倒轉，接口隔離，分解/聚合准繩，開放-關閉 。
1. 開閉准繩(Open-Closed Principle, OCP)
界說：軟件實體應該對擴大開放，對修正封閉。這句話說得有點專業，更淺顯一點講，也就是：軟件體系中包括的各類組件，例如模塊（Modules）、類（Classes）和功效（Functions）等等，應當在不修正現有代碼的基本上，去擴大新功效。開閉准繩華夏有“開”，是指關於組件功效的擴大是開放的，是許可對其停止功效擴大的；開閉准繩中“閉”，是指關於代碼的修正是關閉的，即不該該修正原本的代碼。
成績由來：凡事的發生都有啟事。我們來看看，開閉准繩的發生啟事。在軟件的性命周期內，由於變更、進級和保護等緣由須要對軟件原有代碼停止修正時，能夠會給舊代碼中引入毛病，也能夠會使我們不能不對全部功效停止重構，而且須要原有代碼經由從新測試。這就對我們的全部體系的影響特殊年夜，這也充足展示出了體系的耦合性假如太高，會年夜年夜的增長前期的擴大，保護。為懂得決這個成績，故人們總結出了開閉准繩。處理開閉准繩的基本其實照樣在解耦合。所以，我們面向對象的開辟，我們最基本的義務就是解耦合。
處理辦法：當軟件須要變更時，盡可能經由過程擴大軟件實體的行動來完成變更，而不是經由過程修正已有的代碼來完成變更。
小結：開閉准繩具有幻想主義的顏色，說的很籠統，它是面向對象設計的最終目的。其他幾條准繩，則可以看作是開閉准繩的完成。我們要用籠統構建框架，用完成擴大細節。
2. 單一職責准繩（Single Responsibility Principle）
界說：一個類，只要一個惹起它變更的緣由。即：應當只要一個職責。
每個職責都是變更的一個軸線，假如一個類有一個以上的職責，這些職責就耦合在了一路。這會招致軟弱的設計。當一個職責產生變更時，能夠會影響其它的職責。別的，多個職責耦合在一路，會影響復用性。例如：要完成邏輯和界面的分別。須要解釋的一點是單一職責准繩不只是面向對象編程思惟所獨有的，只需是模塊化的法式設計，都須要遵守這一主要准繩。
成績由來：類T擔任兩個分歧的職責：職責P1，職責P2。當因為職責P1需求產生轉變而須要修正類T時，有能夠會招致本來運轉正常的職責P2功效產生毛病。
處理辦法：分離樹立兩個類T1、T2，使T1完成職責P1功效，T2完成職責P2功效。如許，當修正類T1時，不會使職責P2產生毛病風險；同理，當修正T2時，也不會使職責P1產生毛病風險。
3. 裡氏調換准繩（Liskov Substitution Principle）
界說：子類型必需可以或許調換失落它們的父類型。留意這裡的可以或許兩字。有人也戲稱老鼠的兒子會打洞准繩。
成績由來：有一功效P1，由類A完成。現須要將功效P1停止擴大，擴大後的功效為P，個中P由原有功效P1與新功效P2構成。新功效P由類A的子類B來完成，則子類B在完成新功效P2的同時，有能夠會招致原有功效P1產生毛病。
處理辦法：類B繼續類A時，除添加新的辦法完成新增功效P2外，盡可能不要重寫父類A的辦法，也盡可能不要重載父類A的辦法
小結：一切援用父類的處所必需能通明地應用其子類的對象。子類可以擴大父類的功效，但不克不及轉變父類原本的功效，即：子類可以完成父類的籠統辦法，子類也中可以增長本身獨有的辦法，但不克不及籠罩父類的非籠統辦法。當子類的辦法重載父類的辦法時，辦法的前置前提（即辦法的形參）要比父類辦法的輸出參數更寬松。當子類的辦法完成父類的籠統辦法時，辦法的後置前提（即辦法的前往值）要比父類更嚴厲。
4. 迪米特軌則（Law Of Demeter）
界說：迪米特軌則又叫起碼曉得准繩，即：一個對象應當對其他對象堅持起碼的懂得。假如兩個類不用彼此直接通訊，那末這兩個類就不該當產生直接的互相感化。假如個中一個類須要挪用另外一個類的某一個辦法的話，可以經由過程圈外人轉發這個挪用。簡略界說為只與直接的同伙通訊。起首來說明一下甚麼是直接的同伙：每一個對象都邑與其他對象有耦合關系，只需兩個對象之間有耦合關系，我們就說這兩個對象之間是同伙關系。耦合的方法許多，依附、聯系關系、組合、聚合等。個中，我們稱湧現成員變量、辦法參數、辦法前往值中的類為直接的同伙，而湧現在部分變量中的類則不是直接的同伙。也就是說，生疏的類最好不要作為部分變量的情勢湧現在類的外部。
成績由來：類與類之間的關系越親密，耦合度越年夜，當一個類產生轉變時，對另外一個類的影響也越年夜。
最早是在1987年由美國Northeastern University的Ian Holland提出。淺顯的來說，就是一個類對本身依附的類曉得的越少越好。也就是說，關於被依附的類來講，不管邏輯何等龐雜，都盡可能地的將邏輯封裝在類的外部，對外除供給的public辦法，纰謬外洩露任何信息。迪米特軌則還有一個更簡略的界說：只與直接的同伙通訊。
處理辦法：盡可能下降類與類之間的耦合。 自從我們接觸編程開端，就曉得了軟件編程的總的准繩：低耦合，高內聚。不管是面向進程編程照樣面向對象編程，只要使各個模塊之間的耦合盡可能的低，能力進步代碼的復用率。
迪米特軌則的初志是下降類之間的耦合，因為每一個類都削減了不用要的依附，是以切實其實可以下降耦合關系。然則凡事都有度，固然可以免與非直接的類通訊，然則要通訊，必定會經由過程一個“中介”來產生接洽。故過火的應用迪米特准繩，會發生年夜量如許的中介和傳遞類，招致體系龐雜度變年夜。所以在采取迪米特軌則時要重復衡量，既做到構造清楚，又要高內聚低耦合。
5. 依附顛倒准繩（Dependence Inversion Principle）
界說：高層模塊不該該依附低層模塊，兩者都應當依附其籠統；籠統不該該依附細節；細節應當依附籠統。中間思惟是面向接口編程
成績由來：類A直接依附類B，假設要將類A改成依附類C，則必需經由過程修正類A的代碼來殺青。這類場景下，類A普通是高層模塊，擔任龐雜的營業邏輯；類B和類C是低層模塊，擔任根本的原子操作；假設修正類A，會給法式帶來不用要的風險。
處理辦法：將類A修正為依附接口I，類B和類C各自完成接口I，類A經由過程接口I直接與類B或許類C產生接洽，則會年夜年夜下降修正類A的概率。
在現實編程中，我們普通須要做到以下3點：
1）. 低層模塊盡可能都要有籠統類或接口，或許二者都有。
2）. 變量的聲明類型盡可能是籠統類或接口。
3）. 應用繼續時遵守裡氏調換准繩。
采取依附顛倒准繩特別給多人協作開辟帶來了極年夜的方便，介入協作開辟的人越多、項目越宏大，采取依附招致准繩的意義就越嚴重。
小結：依附顛倒准繩就是要我們面向接口編程，懂得了面向接口編程，也就懂得了依附顛倒。
6. 接口隔離准繩（Interface Segregation Principle）
界說：客戶端不該該依附它不須要的接口；一個類對另外一個類的依附應當樹立在最小的接口上。
成績由來：類A經由過程接口I依附類B，類C經由過程接口I依附類D，假如接口I關於類A和類B來講不是最小接口，則類B和類D必需去完成他們不須要的辦法
處理辦法：1、 應用拜托分別接口。2、 應用多重繼續分別接口。3.將癡肥的接口I拆分為自力的幾個接口，類A和類C分離與他們須要的接口樹立依附關系。也就是采取接口隔離准繩。
舉例解釋：
上面我們來看張圖，一切就了如指掌了。
這個圖的意思是：類A依附接口I中的辦法1、辦法2、辦法3，類B是對類A依附的完成。類C依附接口I中的辦法1、辦法4、辦法5，類D是對類C依附的完成。關於類B和類D來講，固然他們都存在著用不到的辦法（也就是圖中白色字體標志的辦法），但因為完成了接口I，所以也必需要完成這些用不到的辦法
修正後：
假如接口過於癡肥，只需接口中湧現的辦法，不論對依附於它的類有無用途，完成類中都必需去完成這些辦法，這明顯不是好的設計。假如將這個設計修正為相符接口隔離准繩，就必需對接口I停止拆分。在這裡我們將原本的接口I拆分為三個接口
小結：我們在代碼編寫進程中，應用接口隔離准繩，必定要過度，接口設計的過年夜或太小都欠好。對接口停止細化可以進步法式設計靈巧性是不掙的現實，然則假如太小，則會形成接口數目過量，使設計龐雜化。所以必定要過度。設計接口的時刻，只要多花些時光去思慮和計劃，就可以精確地理論這一准繩。
7. 分解/聚合准繩(Composite/Aggregate Reuse Principle,CARP)
界說：也有人叫做分解復用准繩，及盡可能應用分解/聚合，盡可能不要應用類繼續。換句話說，就是能用分解/聚合的處所，毫不用繼續。
為何要盡可能應用分解/聚合而不應用類繼續？
1. 對象的繼續關系在編譯時就界說好了，所以沒法在運轉時轉變從父類繼續的子類的完成
2. 子類的完成和它的父類有異常慎密的依附關系，以致於父類完成中的任何變更必定會招致子類產生變更
3. 當你復用子類的時刻，假如繼續上去的完成不合適處理新的成績，則父類必需重寫或許被其它更合適的類所調換，這類依附關系限制了靈巧性，並終究限制了復用性。
總結：這些准繩在設計形式中表現的淋淋盡致，設計形式就是完成了這些准繩，從而到達了代碼復用、加強了體系的擴大性。所以設計形式被許多人奉為經典。我們可以經由過程好好的研討設計形式，來漸漸的領會這些設計准繩。
