抽象类
抽象类，只为继承而出现，不定义具体的内容，只规定该有哪些东西
一般抽象类中只放置抽象方法，只规定了返回类型和参数
比如：
人 - 有吃饭，睡觉方法
男人 - 继承人抽象类，必须实现吃饭，睡觉的方法主体
女人 - 继承人抽象类，必须实现吃饭，睡觉方法的主体
抽象类中可以有普通属性，通过子类来使用
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("鼠标停止了"); } }
类库
引用别人写的类
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），都是迪米特法则应用的例子。