抽象类
抽象类,只为继承而出现,不定义具体的内容,只规定该有哪些东西
一般抽象类中只放置抽象方法,只规定了返回类型和参数
比如:
人 - 有吃饭,睡觉方法
男人 - 继承人抽象类,必须实现吃饭,睡觉的方法主体
女人 - 继承人抽象类,必须实现吃饭,睡觉方法的主体
抽象类中可以有普通属性,通过子类来使用
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),都是迪米特法则应用的例子.
来源: http://www.cnblogs.com/ShenG1/p/5771443.html