设计模式

参考资料

图解设计模式

大话设计模式

设计模式之禅

github我见过最好的设计模式

http://c.biancheng.net/view/1...

根本准则

开闭准则

在设计的时候尽可能的思考，需要的变动，新需要来了尽可能少的改变代码，拥抱变动

定义:指的是软件中一个实体，如类、模块和函数应该对扩大凋谢，对批改敞开。

面向形象编程

开闭是对扩大和批改的束缚

强调：用形象构建框架，用实现扩大细节。

长处：进步软件系统的可复用性及可维护性

  • 面向对象最根底的设计准则

  • 领导咱们构建稳固的零碎

    • 代码不是一次性的，更多工夫在保护
    • 大多是代码版本的更新迭代

    • 咱们最好对已有的源码很少批改

      • 个别都是新增扩大，类来批改
      • 可能升高危险

对于变动

  • 逻辑变动

    • 比如说算法从a*b*c变动成a*b+c其实是能够间接批改的，前提是所有依赖或者关联类都依照雷同的逻辑来解决

  • 子模块变动

    • 子模块变动可能间接引起整体也就是高层的变动

  • 可见视图变动

    • 如果说需要上多了一些原有逻辑不存在的，可能这种变动是恐怖的，须要咱们灵便的设计

例子

  • 弹性工作工夫，工夫是固定的，上下班是可变的

顶层接口

接口是标准，形象是实现

通过继承来解决

价格的含意曾经变动了，所以不可能子类间接继承getPrice(),因为以后曾经是折扣价格了，可能须要价格和折扣价格

问题

为什么要遵循开闭准则，从软件工程角度怎么了解这点。

  • 开闭准则对扩大凋谢对批改敞开，程序和需要肯定是一直批改的，咱们须要把共性和根底的货色抽出来，把经常批改的货色让他可能扩大进来，这样咱们程序前期保护的危险就会小很多

为什么重要

  • 对于测试的影响

    • 一处变更可能导致原有测试用例都不论用了

  • 进步复用性

    • 高内聚，低耦合
  • 进步可维护性
  • 面向对象开发的要求

如何应用

  • 形象束缚

  • 参数抽到配置中

    • 例如sql的连贯信息
    • 国际化信息

  • 指定我的项目章程

    • 约定我的项目中Bean都是用主动注入，通过注解来做拆卸
    • 团队成员达成统一
    • 公共类走对立的入口，大家都是用对立的公共类
  • 封装变动
  • 提前预知变动

依赖倒置准则

定义

高层模块不应该依赖低层模块，二者都应该依赖其形象。形象不应该依赖细节，细节应该依赖形象。

说白了就是针对接口编程，不要针对实现编程

什么是倒置

  • 不可分割的原子逻辑是底层模块，原子逻辑在组装就是高层模块

  • 形象就是接口或者抽象类

    • 都不能被实例化的

  • 细节

    • 细节就是具体实现类

长处

  • 通过依赖倒置，可能缩小类和类之间的耦合性，进步零碎的稳定性，进步代码的可读性和稳定性。升高批改程序的危险
例子

public class DipTest {  public static void main(String[] args) {    //=====  V1  ========    //        Tom tom = new Tom();    //        tom.studyJavaCourse();    //        tom.studyPythonCourse();    //        tom.studyAICourse();    //=====  V2  ========    //        Tom tom = new Tom();    //        tom.study(new JavaCourse());    //        tom.study(new PythonCourse());    //=====  V3  ========    //        Tom tom = new Tom(new JavaCourse());    //        tom.study();    //=====  V4  ========    Tom tom = new Tom();    tom.setiCourse(new JavaCourse());    tom.study();  }}

重点

  • 先顶层后细节
  • 自顶向下来思考全局不要一开始沉浸于细节
  • 高层不依赖于低层，关系应该用形象来保护
  • 针对接口编程不要针对实现编程
以形象为基准比以细节为基准搭建起来的架构要稳固得多，因而大家在拿到需要之后， 要面向接口编程，先顶层再细节来设计代码构造。

问题

为什么要依赖形象，形象示意我还能够扩大还没有具体实现，依照本人的话来解释一遍

  • 个别软件中形象分成两种，接口和抽象类，接口是标准，形象是模板，咱们通过形象的形式，也就是应用标准和模板这样咱们可能使得下层，也就是调用层可能复用逻辑，而咱们底层是可能疾速更改实现的，例如Spring的依赖注入，Dubbo的SPI，SpringBoot的SPI都如此

依赖的常见写法

  • 结构传递依赖对象
  • setter办法传递依赖对象
  • 接口申明传递对象

最佳实际

  • 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备这是依赖倒置的根本要求，接口和抽象类都是属于形象的，有了抽 象才可能依赖倒置。

  • 变量的外表类型尽量是接口或者是抽象类

    • 很多书上说变量的类型肯定要是接口或者是抽象类，这个有点相对 化了，比方一个工具类，xxxUtils个别是不须要接口或是抽象类的。还 有，如果你要应用类的clone办法，就必须应用实现类，这个是JDK提供 的一个标准。

  • 任何类都不应该从具体类派生

    • 如果一个我的项目处于开发状态，的确不应该有从具体类派生出子类的 状况，但这也不是相对的，因为人都是会犯错误的，有时设计缺点是在 所不免的，因而只有不超过两层的继承都是能够忍耐的。特地是负责项 目保护的同志，基本上能够不思考这个规定，为什么？保护工作基本上 都是进行扩大开发，修复行为，通过一个继承关系，覆写一个办法就可 以修改一个很大的Bug，何必去继承最高的基类呢？（当然这种状况尽 量产生在不甚了解父类或者无奈取得父类代码的状况下。）

  • 尽量不要覆写基类的办法

    • 如果基类是一个抽象类，而且这个办法曾经实现了，子类尽量不要 覆写。类间依赖的是形象，覆写了形象办法，对依赖的稳定性会产生一 定的影响。

繁多职责准则

不要存在多余一个导致类变更的起因

  • 类
  • 接口
  • 办法

只负责一项职责

如果不是这样设计，一个接口负责两个职责，一旦需要变更，批改其中一个职责的逻辑代码会导致另外一个职责的性能产生故障。

案例

用户信息案例

上述图片用户的属性和用户的行为并没有离开

  • 下图把

    • 用户信息抽成BO(Business Object,业务对象)
    • 用户行为抽成Biz(Business Logic 业务逻辑对象)

电话

电话通话会产生上面四个过程

  • 拨号
  • 通话
  • 回应
  • 挂机

上图的接口做了两个事件

  • 协定治理

    • dial 拨号接通
    • hangup 挂机

  • 数据传送

    • chat

引起变动的点

  1. 协定接通会引起会引起变动(连贯导致不传输数据)
  2. 能够有不同的通话形式打电话，上网

从下面能够看到蕴含了两个职责，应该思考拆分成两个接口

长处

  • 类的复杂性升高，实现什么职责都有清晰明确的定义；
  • 可读性进步，复杂性升高，那当然可读性进步了；
  • 可维护性进步，可读性进步，那当然更容易保护了；
  • 变更引起的危险升高，变更是必不可少的，如果接口的繁多职责 做得好，一个接口批改只对相应的实现类有影响，对其余的接口无影响，这对系统的扩展性、维护性都有十分大的帮忙。

留神

繁多职责准则提出了一个编写程序的规范，用“职责”或“变 化起因”来掂量接口或类设计得是否低劣，然而“职责”和“变动起因”都 是不可度量的，因我的项目而异，因环境而异。

This is sometimes hard to see ，繁多职责的确收到很多因素制约

  • 工期
  • 老本
  • 技术水平
  • 硬件状况
  • 网络状况
  • 政府政策

接口隔离准则

  • 两个类之间的依赖应该建设在最小的接口上
  • 建设繁多接口，不要建设宏大臃肿的接口
  • 尽量细化接口，接口中的办法尽量少

高内聚低耦合

例子

问题

为什么要把IAnimal拆分成IFlyAnimal,ISwimAnimal，不拆分会有什么样的问题

  • 一个类所提供的性能应该是他所真正具备的，不拆分会导致他不提供的性能然而强行须要实现，而且会有臃肿的类呈现
  • 可能适配器模式也是为了解决这个问题吧

最佳实际

  • 一个接口只服务于一个子模块或者业务逻辑
  • 通过业务逻辑压缩接口中的public办法，接口时常去回顾，尽量 让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆办法；
  • 曾经被净化了的接口，尽量去批改，若变更的危险较大，则采纳适配器模式进行转化解决；
  • 理解环境，回绝盲从。每个我的项目或产品都有特定的环境因素，别看到巨匠是这样做的你就照抄。千万别，环境不同，接口拆分的规范就不同。深刻理解业务逻辑，最好的接口设计就出自你的手中！

迪米特法令

一个对象应该对其余对象保障起码的理解,也称起码晓得准则,如果两个类不用彼此间接通信，那么这两个类就不应该产生间接的相互作用，如果其中一个类须要调用另外一个类的某个办法的话，能够通过第三者转发这个调用

可能升高类与类之间的耦合

  • 强调只和敌人交换
  • 呈现在成员变量、办法的输出、输入参数中的类都能够称之为成员敌人类， 而呈现在办法体外部的类不属于敌人类。

这外面感觉有点职责离开的感觉，不同的对象应该关注不同的内容，所做的事件也应该是本人所关怀的

例子

teamLeader只关怀后果，不关怀Course

谬误类图如下

问题

如果当前你要写代码和重构代码你怎么剖析怎么重构？

  1. 先剖析相应代码的职责
  2. 把不同的对象须要关怀的内容抽离进去
  3. 每个对象应该只创立和关怀本人所关怀的局部
  4. 肯定要应用的话能够通过三方来应用
  5. 适合的应用作用域，不要裸露过多的公共办法和非动态的公共办法

留神

迪米特法令要求类“羞涩”一点，尽量不要对外颁布太多的 public办法和非动态的public变量，尽量内敛，多应用private、packageprivate、protected等拜访权限。

在理论的我的项目中，须要适度地思考这个准则，别为了套用准则而做我的项目。准则只是供参考，如果 违反了这个准则，我的项目也未必会失败，这就须要大家在采纳准则时重复 度量，不遵循是不对的，严格执行就是“过犹不及”。

序列化引起的坑

  • 审慎应用Serializable

    • 在一个我的项目中应用 RMI（Remote Method Invocation，近程办法调用）形式传递一个 VO（Value Object，值对象），这个对象就必须实现Serializable接口 （仅仅是一个标志性接口，不须要实现具体的办法），也就是把须要网 络传输的对象进行序列化，否则就会呈现NotSerializableException异 常。忽然有一天，客户端的VO批改了一个属性的拜访权限，从private 变更为public，拜访权限扩充了，如果服务器上没有做出相应的变更， 就会报序列化失败，就这么简略。然而这个问题的产生应该属于我的项目管 理领域，一个类或接口在客户端曾经变更了，而服务器端却没有同步更 新，难道不是项目管理的尽职吗？

遵循的准则

如果 一个办法放在本类中，既不减少类间关系，也对本类不产生负面影响， 那就搁置在本类中。

里氏替换准则

一个软件实体如果可能实用一个父亲的话，那么肯定实用其子类，所有援用父亲的中央必须能通明的应用其子类的对象，子类可能替换父类对象

  • 子类能够实现父类的形象办法，然而不能笼罩父类的非形象办法
  • 子类中能够减少本人特有的办法
  • 子类的办法重载父类的办法时，入参要比父类的办法输出参数更宽松
  • 子类实现父类办法的时候（重写/重载或实现形象办法），办法的后置条件（办法的输入，返回）要比父类更加严格或者相等

例子

价格重写问题

价格不是间接重写，而是新写一个办法

public class JavaDiscountCourse extends JavaCourse {  public JavaDiscountCourse(Integer id, String name, Double price) {    super(id, name, price);  }  public Double getDiscountPrice(){    return super.getPrice() * 0.61;  }}
长方形和正方形问题

public static void resize(Rectangle rectangle){  while (rectangle.getWidth() >= rectangle.getHeight()){    rectangle.setHeight(rectangle.getHeight() + 1);    System.out.println("Width:" +rectangle.getWidth() +",Height:" + rectangle.getHeight());  }  System.out.println("Resize End,Width:" +rectangle.getWidth() +",Height:" + rectangle.getHeight());}
public class Square extends Rectangle {  private long length;  //胜率  @Override  public void setHeight(long height) {    setLength(height);  }}

以后设计会呈现死循环

解决办法

形象接口

public interface QuadRangle {    long getWidth();    long getHeight();}

返回独特的length

public class Square implements QuadRangle {  private long length;  public long getLength() {    return length;  }  public void setLength(long length) {    this.length = length;  }  public long getWidth() {    return length;  }  public long getHeight() {    return length;  }}
以后形式子类就可能随时替换父类了

问题

  1. 你怎么了解里氏替换准则，为什么要保障应用父类的中央能够通明地应用子类

    • 子类必须实现父类中没有实现的办法
    • is-a的问题
    • 如果父类的中央替换成子类不行的话程序复杂性减少，继承反而带来了程序的复杂度
    • 子类只能在父类的根底上减少新的办法

  2. 在具体场景中怎么保障应用父类的中央能够通明地应用子类

    • 父类返回多应用具体实现，入参多应用形象或者说顶层接口
    • 子类能够新增一些本人特有的办法

留神

如果子类不能残缺地实现父类的办法，或者父类的某些办法 在子类中曾经产生“畸变”，则倡议断开父子继承关系，采纳依赖、聚 集、组合等关系代替继承。

尽量避免子类的“共性”，一旦子 类有“共性”，这个子类和父类之间的关系就很难和谐了，把子类当做父 类应用，子类的“共性”被抹杀——冤屈了点；把子类独自作为一个业务 来应用，则会让代码间的耦合关系变得错综复杂——不足类替换的标 准。

合成复用准则

尽可能应用对象组合 has-a组合 或者是 contains-a聚合而不是通过继承来达到软件复用的目标。

  • 继承是白箱复用

    • 所有细节都裸露给了子类

  • 组合和聚合是黑箱复用

    • 对象歪的对象获取不到细节

长处

问题

为什么要多用组合和聚合少用继承

  • 继承是侵入性的
  • Java只反对单继承
  • 升高了代码的灵活性，子类多了很多束缚

  • 加强了耦合性，父类批改的时候须要思考子类的批改

    • 会导致要害代码被批改

总结

如果你只有一把铁锤， 那么任何货色看上去都像是钉子。
  • 适当的场景应用适当的设计准则
  • 须要思考，人力，老本，工夫，品质，不要刻意追求完满
  • 须要多思考能力用好工具
本文由博客群发一文多发等经营工具平台 OpenWrite 公布