面向對象 抽象類、接口、類庫、五大原則

抽象類

抽象類，只爲繼承而出現，不定義具體的內容，只規定該有哪些東西
通常抽象類中只放置抽象方法，只規定了返回類型和參數
好比：
人    - 有吃飯，睡覺方法
男人 - 繼承人抽象類，必須實現吃飯，睡覺的方法主體
女人 - 繼承人抽象類，必須實現吃飯，睡覺方法的主體

抽象類中能夠有普通屬性，經過子類來使用

1.關鍵字：abstract
2.抽象類能夠包含抽象方法和普通方法
3.abstract關鍵字能夠定義方法爲抽象方法，抽象方法能夠沒有函數體
4.抽象類沒法被實例化，抽象類主要作爲一個基類，讓別的類繼承。
5.sealed和abstract關鍵字不能同時出現
6.若是一個子類繼承自抽象類，那麼子類中必須實現全部的抽象方法
7.若是子類中沒有實現父類的抽象方法，那麼該子類必須是抽象類
8.若是一個類裏面包含抽象方法，那麼該類必定是抽象類

有抽象方法的，必定是抽象類
抽象類中，不必定有抽象方法

    //定義抽象類
    public abstract class DongWu
    {
        public void Run()
        {

        }
        public abstract void Eat();
    }

    //作一我的類來繼承抽象類
    public class Ren:DongWu
    {
        public override void Eat()
        {
            Console.WriteLine("吃熟食");
        }
    }

 

 

接口

即極度抽象的類

做用：能夠將程序拆分紅多個模塊，定義子類必須實現的功能

好比：

總公司 --制定了規章制度（接口）--公司必須對員工進行考勤

子公司1--遵循總公司的規章制度--具體實現考勤--打卡
子公司2--遵循總公司的規章制度--具體實現考勤--點名

 

接口和抽象類的區別：

1. 寫法區別
　　關鍵字：interface
　　沒有class關鍵字 類名通常用I開頭
　　不用寫public由於自己就是public，不用寫abstract接口裏面全部的都是抽
　   象的

2. 接口裏面不能包含普通成員
3. 凡是繼承接口的類，所有要實現接口裏面的方法

　　由於團隊開發，每一個人負責一個模塊，我只負責人的基本生活部分，另一我的負責工做部分，還有我的負責娛樂活動部分

    //定義接口
    interface IUSB
    {
        //開始讀取USB
        void Start();

        //關閉USB
        void Stop();
    }

    //作一個鼠標類來實現USB接口
    class ShuBiao:IUSB
    {
        public void Start()
        {
            Console.WriteLine("鼠標啓動了");
        }
        public void Stop()
        {
            Console.WriteLine("鼠標中止了");
        }
    }

 

類庫

引用別人寫的類

一、源代碼方法：
能夠將直接寫好的.cs源代碼文件，添加進個人解決方案文件夾下，在解決方案資源管理器中，
項目上右鍵→添加→現有項，來添加此.cs源代碼文件的使用，須要引入相應的命名空間

二、類庫方法：
一個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），都是迪米特法則應用的例子。