设计模式简析与汇总

预计阅读时间:10 分钟

1、设计模式的种类

设计模式分为三大类:

  • 创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
  • 结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
  • 行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
  • 其实还有两类:并发型模式和线程池模式。

2、面向对象的设计的原则

  • 单一责任原则:让一个类只做一种类型责任,当这个类需要承当其他类型的责任的时候,就需要分解这个类。
  • 开放封闭原则:对扩展是开放的,而对修改是封闭的。
  • 里氏替换原则:当一个子类的实例应该能够替换任何其超类的实例时,它们之间才具有is-A关系
  • 依赖倒置原则:高层模块不应该依赖于低层模块,二者都应该依赖于抽象;抽象不应该依赖于细节,细节应该依赖于抽象
  • 接口分离原则:不能强迫用户去依赖那些他们不使用的接口。换句话说,使用多个专门的接口比使用单一的总接口总要好。
  • 迪米特法则(最少知道原则):一个类对自己依赖的类知道的越少越好。无论被依赖的类多么复杂,都应该将逻辑封装在方法的内部,通过public方法提供给外部。这样当被依赖的类变化时,才能最小的影响该类。
  • 合成复用原则:尽量首先使用组合/聚合的方式,而不是使用继承。

3、设计原则简析

(1)单一职责原则(Single Responsibility Principle)
1)优点

  • 类的复杂性降低,实现什么职责都有清晰明确的定义
  • 可读性提高,复杂性降低
  • 可维护性提高,变更引起的风险降低

2)扩展:单一职责原则适用于接口、类,同时也适用于方法,一个方法尽可能只做一件事,例如
坏的设计:一个方法承担多个职责坏的设计:一个方法承担多个职责
好的设计:一个方法承担一个职责
好的设计:一个方法承担一个职责
3)注意:设计时尽可能做到职责单一,但是对于实现类切勿生搬硬套该原则,可能会引起类的剧增,这个原则一般在项目中很难得到体现,在项目开发中常常需要考虑环境、工作量、技术水平、硬件资源等,最终得到一个妥协的结果

4)建议:接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化

(2)开放封闭原则(Open Closed Principle)
1)定义:一个软件实体,如类、模块和函数应该对扩展开放,对修改关闭
2)使用

  • 抽象约束:通过接口或抽象类约束扩展,对扩展进行边界限定
  • 封装变化:将相同的变化封装到一个接口或抽象类中,不应该有两个不同的变化出现在同一个接口或抽象类中

(3)里氏替换原则(Liskov Substitution Principle)
1)优点

  • 代码共享,减少创建类的工作量,每个子类都拥有父类的方法和属性
  • 提高代码的可扩展性

2)缺点

  • 继承具有侵入性,只要继承,就必须拥有父类的所有属性和方法
  • 降低代码的灵活性
  • 增加了耦合性,当父类的常量、变量和方法被修改时,需要考虑子类的修改

3)特点

  • Java使用extends关键字来实现继承,只能单一继承
  • 覆盖或实现父类的方法时输入参数可以被放大,准确地说,子类中方法的入参必须比父类中被覆写
public class Father{
    public Collection doSomething(HashMap map){
        System.out.println("父类被执行");
        return map.values();
    }
}
public class Son extends Father{
    // 输入参数放大,注意不是覆写(Override)父类方法,虽然方法名相同,但输入参数不同
    public Collection doSomething(Map map){
        System.out.println("子类被执行");
        return map.values();
    }
}
public class Client{
    public static void invoker(){
        // 有父类的地方,就可以用子类
        // Father f = new Father();
        Son f = new Son();
        HashMap map = new HashMap();
        f.doSomething(map);
    }
    public static void main(String[] args){
        invoker();
    }
}
  • 覆写或实现父类的方法时输出结果可以被缩小

4)定义:所有引用基类的地方必须能透明地使用其子类的对象,通俗的讲,只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何错误或异常,使用者根本不能觉察出时父类还是子类,注意反过来就不行了,有子类的地方,父类未必适应

5)建议:如果子类不能完整地实现父类的方法,或者父类的某些方法在子类中已经发生“畸变”,建议断开父子继承关系,采用依赖、聚集、组合等关系代替继承

(4)依赖倒置原则(Dependence Inversion Principle)

1)定义

  • 高层模块不应该依赖低层模块,两者都应该依赖其抽象
  • 抽象不应该依赖细节
  • 细节应该依赖抽象

总结:抽象指的就是接口或抽象类,两者都是不能被直接实例化的;细节就是实现类。模块间的依赖应该通过抽象产生,实现类之间不发生直接的依赖关系,实现类依赖接口或抽象类,反之不可。

2)优点:依赖倒置原则可以减少类间的耦合性,提高系统的稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性

3)建议:客户端代码属于高层业务逻辑,它对低层模块的依赖都建立在抽象上

(5)接口隔离原则(Interface Segregation Principle)
1)定义:类的依赖关系应该建立在最小的接口上,应当具有“接口尽量小”、“接口要高内聚”、“接口设计是有限度的”等特点,尽量保证接口的纯洁性

2)建议

  • 一个接口只服务于一个子模块或业务逻辑
  • 通过业务逻辑压缩接口中的public方法,接口时常去回顾
  • 已经被污染的接口,尽量去修改,若转化的风险较大,则采用适配器模式进行转化

(6)迪米特法则(Law of Demeter)
1)定义:一个对象应该对其他对象有最少的了解,对类的低耦合提出了明确的要求
2)建议:尽量不要对外公布太多的public方法和非静态的public变量,多使用private、protected等访问权限

(7)合成复用原则(Composite Reuse Principle)
1)定义:尽量使用对象组合/聚合, 而不是继承关系达到软件复用的目的,继承实际上破坏了类的封装性,超类的方法可能会被子类修改。

2)使用:通过将已有的对象纳入新对象中,作为新对象的成员对象来实现的,新对象可以调用已有对象的功能,从而达到复用。

3)建议:在软件复用时,要尽量先使用组合或者聚合等关联关系来实现,其次才考虑使用继承关系来实现。如果要使用继承关系,则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的,两者都是开闭原则的具体实现规范。

4、总结

设计原则是软件设计模式必须尽量遵循的原则,各种原则要求的侧重点不同。
1)开闭原则是总纲,它告诉我们要对扩展开放,对修改关闭;
2)里氏替换原则告诉我们不要破坏继承体系;
3)依赖倒置原则告诉我们要面向接口编程;
4)单一职责原则告诉我们实现类要职责单一;
5)接口隔离原则告诉我们在设计接口的时候要精简单一;
6)迪米特法则告诉我们要降低耦合度;
7)合成复用原则告诉我们要优先使用组合或者聚合关系复用,少用继承关系复用。

尾注

  • 上述的总结与思考是基于对《设计模式之禅》这本书的精读与演绎
  • 更多及时干货,请关注微信公众号:JAVA万维猿圈
    在这里插入图片描述
  • 2
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值