面向对象七大设计原则
1、 开闭原则
2、 里氏替换原则
3、 单一职责原则
4、 接口隔离原则
5、 依赖倒置原则
6、 迪米特原则
7、组合/聚合复用原则
一、开闭原则:
这一条放在第一位来理解,它的含义是对扩展开放,对修改关闭。解释一下就是,我们写完的代码,不能因为需求变化就修改。我们可以通过新增代码的方式来解决变化的需求。
当然,这是一种理想的状态,在现实中,我们要尽量的缩小这种修改。
再解释一下这条原则的意义所在,我们采用逆向思维方式来想。如果每次需求变动都去修改原有的代码,那原有的代码就存在被修改错误的风险,当然这其中存在有意和无意的修改,都会导致原有正常运行的功能失效的风险,这样很有可能会展开可怕的蝴蝶效应,使维护工作剧增。
说到底,开闭原则除了表面上的可扩展性强以外,在企业中更看重的是维护成本。
所以,开闭原则是设计模式的第一大原则,它的潜台词是:控制需求变动风险,缩小维护成本。
以下几种原则,都是为此原则服务的。
二、里氏替换选择:
此原则的含义是子类可以在任何地方替换它的父类。解释一下,这是多态的前提,我们后面很多所谓的灵活,都是不改变声明类型的情况下,改变实例化类来完成的需求变更。当然,继承的特性看似天然就满足这个条件。但这里更注重的是继承的应用问题,我们必须保证我们的子类和父类划分是精准的。
里氏替换原则的潜台词是:尽量使用精准的抽象类或者接口。
三、单一职责原则:
单一职责的含义是:类的职责单一,引起类变化的原因单一。解释一下,这也是灵活的前提,如果我们把类拆分成最小的职能单位,那组合与复用就简单的多了,如果一个类做的事情太多,在组合的时候,必然会产生不必要的方法出现,这实际上是一种污染。
举个例子,我们在绘制图案的时候,用“点”组成图和用“直线”组成图,哪个更灵活呢?一定是“点”,它可以绘制任何图形,而直线只能绘制带有直线条的图案,它起码无法画圆。
单一职责的潜台词是:拆分到最小单位,解决复用和组合问题。
四、接口隔离原则:
接口隔离原则可以说是单一职责的必要手段,它的含义是尽量使用职能单一的接口,而不使用职能复杂、全面的接口。很好理解,接口是为了让子类实现的,如果子类想达到职能单一,那么接口也必须满足职能单一。
相反,如果接口融合了多个不相关的方法,那它的子类就被迫要实现所有方法,尽管有些方法是根本用不到的。这就是接口污染。
接口隔离原则的潜台词是:拆分,从接口开始。
五、依赖倒置原则:
想要理解依赖倒置原则,必须先理解传统的解决方案。面相对象的初期的程序,被调用者依赖于调用者。也就是调用者决定被调用者有什么方法,有什么样的实现方式,这种结构在需求变更的时候,会付出很大的代价,甚至推翻重写。
依赖倒置原则就是要求调用者和被调用者都依赖抽象,这样两者没有直接的关联和接触,在变动的时候,一方的变动不会影响另一方的变动。
其实,依赖倒置和前面的原则是相辅相成的,都强调了抽象的重要性。
依赖倒置的潜台词是:面向抽象编程,解耦调用和被调用者。
六、迪米特原则:
迪米特原则要求尽量的封装,尽量的独立,尽量的使用低级别的访问修饰符。这是封装特性的典型体现。
一个类如果暴露太多私用的方法和字段,会让调用者很茫然。并且会给类造成不必要的判断代码。所以,我们使用尽量低的访问修饰符,让外界不知道我们的内部。这也是面向对象的基本思路。这是迪米特原则的一个特性,无法了解类更多的私有信息。
另外,迪米特原则要求类之间的直接联系尽量的少,两个类的访问,通过第三个中介类来实现。
迪米特原则的潜台词是:不和陌生人说话,有事去中介。
七、组合/聚合复用原则:
此原则的含义是,如果只是达到代码复用的目的,尽量使用组合与聚合,而不是继承。这里需要解释一下,组合聚合只是引用其他的类的方法,而不会受引用的类的继承而改变血统。
继承的耦合性更大,比如一个父类后来添加实现一个接口或者去掉一个接口,那子类可能会遭到毁灭性的编译错误,但如果只是组合聚合,只是引用类的方法,就不会有这种巨大的风险,同时也实现了复用。
组合聚合复用原则的潜台词是:我只是用你的方法,我们不一定是同类。
2、 在学习面向对象七大设计原则时需要注意以下几点:
a) 高内聚、低耦合和单一职能的“冲突”
实际上,这两者是一回事。内聚,要求一个类把所有相关的方法放在一起,初看是职能多,但有个“高”,就是要求把联系非常紧密的功能放在一起,也就是说,从整体看,是一个职能的才能放在一起,所以,两者是不同的表述而已。
这里很多人理解成复合类,但复合类不是高内聚,而是杂乱的放在一起,是一种设计失误而已。
b) 多个单一职能接口的灵活性和声明类型问题
如果一个类实现多个接口,那么这个类应该用哪个接口类型声明呢?应该是用一个抽象类来继承多个接口,而实现类来继承这个接口。声明的时候,类型是抽象类。
c) 最少知识原则和中介类泛滥两种极端情况
这是另一种设计的失误。迪米特原则要求类之间要用中介来通讯,但类多了以后,会造成中介类泛滥的情况,这种情况,我们可以考虑中介模式,用一个总的中介类来实现。
当然,设计模式都有自己的缺陷,迪米特原则也不是十全十美,交互类非常繁多的情况下,要适当的牺牲设计原则。
d) 继承和组合聚合复用原则的“冲突”
继承也能实现复用,那这个原则是不是要抛弃继承了?不是的。
继承更注重的是“血统”,也就是什么类型的。而组合聚合更注重的是借用“技能”。并且,组合聚合中,两个类是部分与整体的关系,组合聚合可以由多个类的技能组成。在C#和Java中只有单继承。
这个原则不是告诉我们不用继承了,都用组合聚合,而是在“复用”这个点上,我们优先使用组合聚合。
七种设计原则总结:
单一职责原则:一个类只应该做和一个职责相关的事情,不要把过多的业务放在一个类中完成。
迪米特法则:软件实体之间应该做到最少的交互。不要和陌生人说话。调用方只关心他需要使用的方法
接口隔离原则:使用专门的接口,比用统一的接口要好。便于分工,在实现接口时,不应该看到自己不用关心的方法。
开闭原则:软件实体应该对扩展开放,对修改关闭。开闭原则是设计原则的核心原则,其他的设计原则都是开闭原则表现和补充。实现开闭原则的方法就是抽象。
聚合/组合复用原则。多使用聚合/组合达到代码的重用,少使用继承复用。
依赖倒置原则:面向抽象编程,不要面向具体编程。