面向对象 抽象类、接口、类库、五大原则

抽象类

抽象类，只为继承而出现，不定义具体的内容，只规定该有哪些东西
通常抽象类中只放置抽象方法，只规定了返回类型和参数
好比：
人    - 有吃饭，睡觉方法
男人 - 继承人抽象类，必须实现吃饭，睡觉的方法主体
女人 - 继承人抽象类，必须实现吃饭，睡觉方法的主体

抽象类中能够有普通属性，经过子类来使用

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），都是迪米特法则应用的例子。