一、類庫 引用別人寫的類 1、源代碼方法： 可以將直接寫好的.cs源代碼文件，添加進我的解決方案文件夾下，在解決方案資源管理器中， 項目上右鍵→添加→現有項，來添加此.cs源代碼文件的使用，需要引入相應的命名空間 2、類庫方法： 一個dll文件，就是一個類庫 它人新建一個類庫，在裡面編寫類和相應的方 ...
一、類庫
引用別人寫的類
1、源代碼方法：
可以將直接寫好的.cs源代碼文件，添加進我的解決方案文件夾下，在解決方案資源管理器中， 項目上右鍵→添加→現有項，來添加此.cs源代碼文件的使用，需要引入相應的命名空間
2、類庫方法：
一個dll文件，就是一個類庫 它人新建一個類庫，在裡面編寫類和相應的方法，生成後出現一個dll文件，拿過來，放在自己的 程式文件夾里，在項目右鍵→添加引用→找到此dll類庫文件添加，然後引用命名空間，就可以調用相應的類中的方法了
註意類一定要是public訪問許可權
類庫使用是多公司聯合開發時使用的方式，因為每個公司都有自己的核心技術，我允許你使用，但不允許你 知道我是怎麼編寫的，所以需要dll類庫文件，因為dll文件是將源代碼文件編譯後的文件，看不到源代碼， 所以你只能調用不允許更改
二、五大原則
1.單一職責原則SRP(Single Responsibility Principle)
是指一個類的功能要單一，不能包羅萬象。如同一個人一樣，分配的工作不能太多，否則一天到晚雖然忙忙碌碌的，但效率卻高不起來。
2.開放封閉原則OCP(Open－Close Principle)
一個模塊在擴展性方面應該是開放的而在更改性方面應該是封閉的。例繼承。
比如：一個網路模塊，原來只服務端功能，而現在要加入客戶端功能， 那麼應當在不用修改服務端功能代碼的前提下，就能夠增加客戶端功能的實現代碼，這要求在設計之初，就應當將服務端和客戶端分開，公共部分抽象出來。
3.里氏替換原則(the Liskov Substitution Principle LSP)
子類應當可以替換父類並出現在父類能夠出現的任何地方。
比如：公司搞年度晚會，所有員工可以參加抽獎，那麼不管是老員工還是新員工， 也不管是總部員工還是外派員工，都應當可以參加抽獎，否則這公司就不和諧了。
4.依賴倒置原則(the Dependency Inversion Principle DIP)
具體依賴抽象，上層依賴下層。
假設B是較A低的模塊，但B需要使用到A的功能， 這個時候，B不應當直接使用A中的具體類： 而應當由B定義一抽象介面，並由A來實現這個抽象介面，B只使用這個抽象介面：這樣就達到 了依賴倒置的目的，B也解除了對A的依賴，反過來是A依賴於B定義的抽象介面。通過上層模塊難以避免依賴下層模塊，假如B也直接依賴A的實現，那麼就可能造成迴圈依賴。一個常見的問題就是編譯A模塊時需要直接包含到B模塊的cpp文件，而編譯B時同樣要直接包含到A的cpp文件。
5.迪米特法則（Law of Demeter）
又叫作最少知識原則（Least Knowledge Principle 簡寫LKP），就是說一個對象應當對其他對象有儘可能少的瞭解,不和陌生人說話。
英文簡寫為: LoD.迪米特法則可以簡單說成：talk only to your immediate friends。 對於面向OOD來說，又被解釋為下麵幾種方式：一個軟體實體應當儘可能少的與其他實體發生相互作用。每一個軟體單位對其他的單位都只有最少的知識，而且局限於那些與本單位密切相關的軟體單位。 迪米特法則的初衷在於降低類之間的耦合。由於每個類儘量減少對其他類的依賴，因此，很容易使得系統的功能模塊功能獨立，相互之間不存在（或很少有）依賴關係。 迪米特法則不希望類直接建立直接的接觸。如果真的有需要建立聯繫，也希望能通過它的友元類來轉達。因此，應用迪米特法則有可能造成的一個後果就是：系統中存在大量的中介類，這些類之所以存在完全是為了傳遞類之間的相互調用關係——這在一定程度上增加了系統的複雜度。 有興趣可以研究一下設計模式的門面模式（Facade）和中介模式（Mediator），都是迪米特法則應用的例子。
