七大设计原则
设计模式的基本概念
在软件工程中看,设计模式是对软件设计中普遍存在(反复出现)的各种问题,所提出的解决方案。设计模式不是代码,而是某类问题的通用解决方案。设计模式代表着最佳实践。这些解决方案是众多软件人员的试错和总结。设计模式包含了面向对象的精髓,懂得了设计模式,就懂得了面向对象分析和设计的精要。
-
设计模式的本质:
- 提高软件的 “可维护性”,“通用性”,“可扩展性”,并降低"软件的复杂度"。
- 提高软件的 “可维护性”,“通用性”,“可扩展性”,并降低"软件的复杂度"。
-
设计模式的重要性
- 当项目开发完成时,如果客户提出新增功能怎么办?
==> 可扩展性 - 当项目开发完成时,程序员离职时,需要接受维护怎么办?
==> 可维护性,可读性, 规范性 - 在实际项目中用过什么设计模式?怎么使用的?解决了哪些问题?
- 设计模式在软件的什么位置?
面向对象OOP ==> 功能模块 (设计模式+数据结构+算法) ==> 框架(使用多种设计模式) ==> 架构(服务器集群)
- 当项目开发完成时,如果客户提出新增功能怎么办?
-
设计模式的目的
- 代码可重用性 ==> 相同功能的代码,不用多次编写。
- 代码可读性 ==> 编码规范性,便于其他人阅读和理解。
- 代码可扩展性 ==>当需要新增功能时,非常方便,易维护。
- 代码可靠性 ==>新增功能时,对原来的功能没有影响。
- 高内聚,低耦合 ==>对外呈现高内聚,低耦合。
-
核心思想:
- 找出应用中可能需要变化的地方,把它们独立出来。不要和那些不需要的代码混合在一起。
- 针对接口编程,而不针对实现类编程。
- 为交互对象之间的松耦合设计而努力。
24种设计模式
- 创建型模式
- 单例模式, 工厂方法模式,抽象工厂模式,原型模式, 建造者模式
- 结构型模式
- 适配器模式, 桥接模式, 装饰模式, 组合模式, 外观模式, 享元模式,代理模式
- 行为型模式
- 模板方法模式,命令模式,访问者模式, 迭代器模式,观察者模式,中介者模式, 备忘录模式,解释器模式,状态模式,策略模式, 责任链模式
- 模板方法模式,命令模式,访问者模式, 迭代器模式,观察者模式,中介者模式, 备忘录模式,解释器模式,状态模式,策略模式, 责任链模式
设计模式常用的七大原则
- 1、单一职责原则
- 2、接口隔离原则
- 3、依赖倒转原则
- 4、里氏替换原则
- 5、开闭原则OCP
- 6、迪米特法则(最少知道原则)
- 7、合成复用原则
一、单一职责原则
- 基本概念
对类来说,一个类只负责一项职责。如果类负责两个不同的职责:职责A和职责B,当职责A的需求发生改变时,则类中的代码发生改变,此时可能造成职责A和职责B的代码发生改变而造成错误,以及要重新进行单元测试。所以最好是将类进行单一职责的粒度进行分解。- 由于有多个职责,则由于改动而需要维护的代码更多
- 只有当类中逻辑足够简单,才可以在代码级别违反单一原则,只有当类中方法数量足够少时,可在方法级别上保持单一职责原则。
- 优点
- 降低了类的复杂度,一个类只负责一项职责。
- 提高类的可读性,可维护性。
- 降低了变更代码引起的风险。
- 通常情况下,我们应该遵循单一职责原则,除非逻辑足够简单,可以在放方法级别保持单一职责原则。
#b,c表示两类不同的功能
public class A {
public void b(){
...
}
public void c(){
...
}
}
==>
public class AB {
public void b(){
...
}
}
public class AC {
public void c(){
...
}
}
二、接口隔离原则
传统方法的问题和接口隔离原则的改进
- 传统方法的问题:
==>类A通过接口interface依赖B, 类C通过接口interface依赖类D,如果接口interface对于类A和类C不是最小接口,那么类B和类D就必须要去实现他们不需要的方法。
- 接口隔离原则:
==>将接口interface拆分成独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系,保持接口的最小依赖。这就是接口分离原则。
#类A通过interface E依赖类C, 其只依赖a(),b()方法
public class A {
private E e;
public A( E e ){
this.e = e;
this.e.a();
this.e.b();
}
}
#类C通过interface E依赖类D,且只依赖c(),d()方法
public class C {
private E e;
public C( E e ){
this.e = e;
this.e.c();
this.e.d();
}
}
#接口E
public interface E {
public void a();
public void b();
public void c();
public void d();
}
public class B implements E {
...
}
public class D implements E {
...
}
- 根据接口隔离原则进行改进
#类A通过interface E依赖类C, 其只依赖a(),b()方法
public class A {
private E e;
public A( E e ){
this.e = e;
this.e.a();
this.e.b();
}
}
#类C通过interface F依赖类D,且只依赖c(),d()方法
public class C {
private F f;
public C( F f ){
this.f = f;
this.f.c();
this.f.d();
}
}
public interface E {
public void a();
public void b();
}
public interface F {
public void c();
public void d();
}
public class B implements E {
...
}
public class D implements F {
...
}
三、依赖倒转原则
- 高层模块不应该依赖底层模块,二者都应该依赖其抽象。层之间依赖接口。
- 抽象不应该依赖细节,细节应该依赖抽象。
- 依赖倒转的核心思想:面向接口编程。
- 依赖倒转原则是基于以下的设计理念:
- 相对于细节的多变性,抽象的东西要稳定很多。以抽象为基础搭建的架构比以细节为基础搭建的架构要稳定的多。在java中,抽象是指接口或者抽象类,细节就是具体的实现类。
- 使用接口或者抽象类的目的是制定好规范,而不涉及任何具体的操作,把战线细节的任务交给他们的实现类去完成。
依赖倒转的核心思想就是:面向接口编程。层与层之间通过接口来访问。不要在类的内部去new所依赖的对象,而是通过依赖关系传递到类内部来。
-
依赖关系传递的三种方式:
- 接口传递依赖;
public interface IOpenAndClose { public void open( TV tv ); } public interface TV { public void play(); } public class AqyTV implements TV { public void play(){ System.out.println("hello aqy!"); } } public OpenAndClose implements IOpenAndClose { public void open( TV tv ) { tv.play(); } public static void main( String[] args ){ IOpenAndClose iOpenAndClose = new OpenAndClose(); iOpenAndClose.open( new AqyTV() ); } }
- 构造方法传递依赖;
public interface IOpenAndClose { public void open(); } public interface TV { public void play(); } public class AqyTV implements TV { public void play(){ System.out.println("hello AqyTV!"); } } public class OpenAndClose implements IOpenAndClose { private TV tv; public OpenAndClose( TV tv ){ this.tv = tv; } public static void main( String[] args ){ IOpenAndClose iOpenAndClose = new OpenAndClose(new AqyTV()); iOpenAndClose.open(); } }
- setter方式传递依赖;
public interface IOpenAndClose { public void open(); public void setTV( TV tv ); } public interface TV { public void play(); } public class AqyTV implements TV { public void play(){ System.out.println("hello AqyTV!"); } } public class OpenAndClose implements IOpenAndClose { private TV tv; public void setTV( TV tv ){ this.tv = tv; } public static void main( String[] args ){ IOpenAndClose iOpenAndClose = new OpenAndClose(new AqyTV()); iOpenAndClose.open(); } }
依赖倒转原则的注意事项和细节:
- 底层模块(被依赖或者被调用的组件)尽量使用抽象类或者接口,或者两者都有,程序稳定性会更好。
- 变量的声明类型尽量是抽象类或者接口,这样我们的变量引用和实际对象间,就存在一个缓冲层,利用实现接口的实体类进行扩展和优化。
- 继承时准寻里氏替换原则。
四、里氏替换原则
- 如果对每个类型为T1的对象O1,都有类型为T2的对象O2,使得以T1定义的所有程序在所有的对象O1都代换为O2时,程序的行为没有发生变化,那么类型T2是类型T1的子类型。换句话说:素所有引用基类的地方都必须能透明的使用其子类的对象。即子类继承于父类的方法,行为保持一致,不要去重写覆盖。
- 在使用继承时,遵循里氏原则,在子类中尽量不要重写父类的方法,这样在版本迭代时,能保持较好的向下兼容性。
- 里氏原则告诉我们: 继承为让两个类之间的耦合增强,如果修改父类代码时,则会影响到子类的使用。修改子类继承于父类的代码,也会导致兼容性问题出现。在适当的情况下,可以通过聚合,组合,依赖来解决问题。
针对继承父类方法,又不得不重写父类方法的处理方案
- 可以解除继承关系,而是通过聚合,组合的方式来结局问题。
- 也可以让原有的父子继承关系解除,让不要重写的方法提取到一个公共的基类(编程一个虚拟类),让需要重写的方法在原来的父子类中分别实现。
子类重写父类方法的情形
public interface A {
public void a();
public void b();
public void c();
public void d();
}
public class B implements A {
public void a(){
System.out.println("B-a");
}
public void b(){
System.out.println("B-b");
}
public void c(){
System.out.println("B-c");
}
public void d(){
System.out.println("B-d");
}
}
public class C extends B {
public void a(){
System.out.println("B-a");
}
public void b(){
System.out.println("B-b");
}
public void c(){
System.out.println("C-c");
}
public void d(){
System.out.println("C-d");
}
}
遵循里氏替换原则的继承处理
- 将共有方法提取到公共的抽象类,不相同行为的方法单独实现。
public interface A {
public void a();
public void b();
public void c();
public void d();
}
public abstract class D {
public void a() {
System.out.println("D-a");
}
public void b(){
System.out.println("D-b");
}
public abstract void c();
public abstract void d();
}
public class B extends D {
public void c(){
System.out.println("B-c");
}
pulic void d(){
System.out.println("B-d");
}
}
public class C {
public void c(){
System.out.println("C-c");
}
pulic void d(){
System.out.println("C-d");
}
}
五、开闭原则
- 开闭原则: 最基础,最重要的设计原则。
==> 一个软件如类,模块和函数应该对提供方扩展开放,对使用方修改关闭。。用抽象构建框架,用实现扩展细节。 - 当软件需求发生变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。(扩展行为,不要轻易去修改已有的使用方中的代码)。
- 编程中遵循其他原则,以及使用设计模式的目的就是为了遵循开闭原则。提供方不允许修改代码。通过新增来扩展新功能。使用方不允许新增或者修改。(当做第三方库来对待使用方的代码)。
#通过接口传递依赖关系,根据多态来动态新增功能
public interface A {
public void setTV( TV tv );
}
public interface TV {
public void play();
}
public class IqyTV implements TV {
public void play(){
System.out.println("hello iqyTV");
}
}
public class B implements A {
private TV tv;
public void setTV( TV tv ){
this.tv = tv;
}
public static void main( String[] args ){
A a = new B();
a.setTV( new IqyTV() );
a.tv.play();
}
}
六、迪米特法则(最少知道原则)
- 一个对象应该对其他对象保持最少的了解。类与类之间的关系越密切,耦合度越大。
- 迪米特法则:又称为最少知道原则,即一个类对自己依赖的类知道的越少越好。也就是说: 对于被依赖的类,不管多复杂,都尽量将逻辑封装在类的内部,对外除了提供的必要的public方法,不对外泄露任何信息。
关于迪米特法则的简单定义:
- 只与直接朋友通信,且直接朋友也只提供public方法,不暴露内部逻辑。
关于直接朋友:
- 任何两个对象之间都有耦合关系,只要有耦合关系,就是朋友。耦合的方式有很多:依赖,关联,组合,聚合等。其中出现在成员变量,方法参数,方法返回值中的类称为直接朋友。出现在方法中的局部变量中的类不是直接朋友。(陌生类最好不要以局部变量的形式出现在类的内部)
七、合成复用原则
- 合成复用原则:
- 能用合成,聚合的方式,就不推荐用继承。
- 能用合成,聚合的方式,就不推荐用继承。