作者:muggle

设计模式的分类

创建型模式

共五种:

  • 工厂方法模式
  • 抽象工厂模式
  • 单例模式
  • 建造者模式
  • 原型模式

结构型模式

共七种:

  • 适配器模式
  • 装饰器模式
  • 代理模式
  • 外观模式
  • 桥接模式
  • 组合模式
  • 享元模式

行为型模式

共十一种:

  • 策略模式

  • 模板方法模式

  • 观察者模式

  • 迭代子模式

  • 责任链模式

  • 命令模式

  • 备忘录模式

  • 状态模式

  • 访问者模式

  • 中介者模式

  • 解释器模式

    设计原则

设计模式的最终目的是为了实现代码设计的六大基本原则的,我们在使用设计模式的时候千万要记住这一点,不用为了使用设计模式而去强行套设计模式

单一职责原则

不要存在多于一个导致类变更的原因,也就是说每个类应该实现单一的职责,如若不然,就应该把类拆分。

当需求变化时,将通过更改职责相关的类来体现。如果一个类拥有多于一个的职责,则多个职责耦合在一起,会有多于一个原因来导致这个类发生变化。一个职责的变化可能会影响到其他的职责,另外,把多个职责耦合在一起,影响复用性。

单一职责原则解决的问题:

  • 降低类的复杂度;
  • 提高类的可读性,提高系统的可维护性;
  • 降低变更引起的风险(降低对其他功能的影响)。

里氏替换原则

任何基类可以出现的地方,子类一定可以出现。

只有当子类可以替换掉父类, 代码功能不受到影响时,父类才能真正被复用, 而子类也能够在父类的基础上增加新的行为;从而达到代码复用与扩展的目的;里氏替换原则中,子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构,通过这个规范的接口与外界交互,子类不应该随便破坏它。

里氏替换原则解决的问题:

  • 增强程序的健壮性, 版本升级时也可以保持非常好的兼容性。
  • 提高代码复用率

依赖倒置原则

这个是开闭原则的基础,具体内容:面向接口编程,依赖于抽象而不依赖于具体。写代码时用到具体类时,不与具体类交互,而与具体类的上层接口交互。

开闭原则

对于引用的模块尽量去扩展,而不是去修改它,也就是所谓的对扩展开放对修改关闭。开闭原则是面向对象的可复用设计的第一块基石,它是最重要的面向对象设计原则,抽象化是开闭原则的关键。

接口隔离原则

接口隔离原则(Interface Segregation Principle, ISP):使用多个专门的接口,而不使用单一的总接口,即客户端不应该依赖那些它不需要的接口。 根据接口隔离原则,当一个接口太大时,我们需要将它分割成一些更细小的接口,使用该接口的客户端仅需知道与之相关的方法即可

迪米特原则

一个类应该对自己需要耦合或调用的类知道得最少,类的内部如何实现、如何复杂都与调用者或者依赖者没关系,调用者或者依赖者只需要知道他需要的方法即可,其他的我一概不关心。类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。

设计模式解析

在使用设计模式时,我们应该先解析问题,将各个问题解析成几个小点,然后每个点所对应的是创造型还是结构型还是行为型,最后从三类设计模式中找出合适的模板。

一个好的设计模式,首先要用对场景,然后命名要规范,要让别人一看命名就知道你用的什么设计模式,然后根据设计模式去找相关联的类,这样别人脑海里才能形成一个脉络,有点没法按设计模式规范命名的地方也请加上注释,不然让别人猜你的代码写了些啥,用的啥设计模式吗?

results matching ""

    No results matching ""