基类，一些比如公共 大家都有的属性，那放在基类 继承了我就不用重复写一些代码和属性了，基类目的是为了减少重复代码，将通用方法放到一起

然后进一步到抽象类，它和普通类一样，但他是一定作为基类来使用

抽象类更像是父亲要求孩子必须要怎么样：
我构造方法的参数我子类的构造参数也必须有，我的抽象方法我的子类也必须实现（父亲强制把传统手艺教给孩子，作为孩子我也可以使用父亲有的资源）

这样我知道还是会不清楚，因为只能在实际用到才知道为什么要有规范，什么情况适合用接口还是抽象类

接口的诞生是从抽象类来的，抽象类是从基类来的，抽象类他可以提要求，也可以实现要求，而接口就很纯粹，我只能提要求，但他可以多继承

他们之间是互补的，规范可以减少出错

抽象类

优点：它和接口一样有规范，也可以和基类一样方便使用

缺点：不可以多继承

接口

优点：解决了抽象类的缺点，可以多继承

缺点：不能和抽象类一样实现方法给子类使用

各有优缺点，所以也可以互相配合使用

而他们使用场景要用到时才会选合适的方法去实现

（继承和实现其实是一样的 称呼不同）

什么情况要用抽象类或者接口规范

c#不是弱类语言，其实更多不是为了规范而规范的使用接口，当需要在方法中传递对象并调用特定方法时，如果没有规范，编译器无法确定传入的对象是否有所需的方法

比如写一个方法，要传递一个对象，这个对象传递过来我还要调用到这个对象的方法，编译器并不知道你有没有这个方法，那我传别对象也可以啊，但别的对象没这个方法名，那就报错了，就好像我写了int类型的参数，但我传了string（对对象做了规范）

列如你要写一个方法并且传递一个未知的对象进来，并且还要使用到这个传递过来的对象中实现的方法。

编译器怎么知道你有这个方法呢，接口/抽象类（作为基类）：类似int string bool，最终的基类是object

编译器：好，我知道你有了，可以调用这个方法名

1.创建了一个请求类的接口

2. 写一个执行请求的通用方法

并且规范了T这个泛型的类型是PopResponse

因为规范了T的类型是PopResponse，所以要返回的Response类都要继承PopResponse

3. 创建请求的对象

继承了IPopRequest就实现他的所有方法

这样不同对象可以拿到不同名称

4.传递对象，执行通用方法

上面是为什么要规范接口的一个案例，同样抽象类也可以实现类似，只不过接口更适合这个情况，因为已经满足了需求

那什么时候用接口什么时候用抽象类

当需要让子类继承成员变量、公共方法 或者需要让子类实例化时用抽象类，否则接口，看需求使用，很相似，但是应该可以理解为接口是更加单一纯粹的抽象类

如果只是为了使用基类的成员变量则不用使用抽象类，除非如上，需要规定子类时