设计模式

单一职责原则

应该只有一个引起类变化的原因

example:

修改之前,存在一个严重错误,用户的属性和对用户的操作在一个类中:

修改前,用户属性和对用户的操作在一个类中

![修改后,分开两种类型的操作](https://yuml.me/diagram/plain/class/[IUserInfo|+setUserId;+getUserId;+setPassword;+getPassword;+setName;+getName],[IUserOp|+changePassword;+deleteUser;+addOrg;+addRole],[IUserInfo]-[IUser],[IUserOp]-[IUser],[IUserOp]-[note:对用户的操作],[IUserInfo]-[note:用户的基本属性] root{bg:wheat} "xxx")
实际情况中,把用户和对用户的操作分成两个类更合适一点:

修改后,分开两种类型的操作

example2:
电话类,有拨号、挂断、通话三个方法:

可以将其中拨号、挂断两个方法放在单独接口中,因为它属于协议管理方法;而通话属于数据传送:

当手机可以上网时,对外的接口不改变。
example3:
把一堆功能放在一个函数,用选项来确定内部逻辑:
![]( https://yuml.me/diagram/plain/class/[UserManager|+changeUser(User user string options)])
修改后:
![]( https://yuml.me/diagram/plain/class/[UserManager|+changeUserName(User user);+changeAddress(User user);+changeTel(User user)])
明确每个函数的功能,不要大杂烩方法。

  • 不要设计超级大的接口,功能杂糅的接口,应该只有一个使得它改变的原因。子类实现大的接口,需要实现所有方法,侵入了子类。
  • 接口的划分没有绝对正确的标准。

里氏替换原则

所有引用父类的地方,可以透明的替换成子类。

  • 子类要扩展父类的方法,不要更改原来的方法
  • 父类可以将方法声明为final,明确告诉子类不要更改父类行为
  • 常说的继承是is-a关系。实际上,不仅仅是现实世界语义上的is-a关系,更重要的是行为上的is-a关系,即不要更改父类方法的原有含义。(想起了go/ruby的duck类型,我不管你是不是继承了子类,我只关系你行为是不是符合语义,只要行为符合,我都认为是子类)
  • 想想一下,有人在子类,把父类小于less()方法复写为大于语义,不知道的人,替换成新子类的时候,心中一定是日了狗了。
  • 子类方法语义和父类不同,就不敢透明替换
  • 只有符合了里氏替换原则,才会符合开闭原则。假设调用父类的地方,都不能安全的替换为子类,那么“对扩展开放”也就不可能。
  • 对于父类的合法输入,对于子类一定合法;子类的输出,一定被父类的输出包括。

依赖倒置原则

高层和底层之间不直接产生依赖关系,上层使用下层的接口。

  • 不要直接去依赖其他类,而是去依赖他的抽象,以后想替换也比较容易

接口隔离原则

将接口按将来可能的变化,划分为几个接口,每个接口独自变化。

  • 接口划分时,要满足单一职责原则,并且接口要有内聚性。
  • 少一个接口方法,就少一个public方法,对外改动的风险就越小。
  • 划分是有粒度的,越小越灵活,越能提供定制化的服务,但是复杂度增加了。
    说白了,接口是筋骨,不要太肥!太肥会拖累子类,而且会让别人没发实现这种接口。

迪米特法则

让使用者只关心公布的接口和方法。

  • 公开的方法越多,修改越麻烦,变更风险越大
  • 类方法只和成员变量、输入输出参数的类产生联系,不和其他陌生类产生联系。
  • 通过构造函数、set方法将依赖对象注入
  • 和其他类解耦,会产生中转依赖的方法

开闭原则

对扩展开放,对修改关闭

  • 使用扩展子类来面对需求变化,而不是更改原来的代码
  • 通过接口或抽象类来约束扩展的行为
  • 尽量依赖抽象,而不是具体的实现类(这点很好理解,尽量面向抽象编程,而不是面向实现编程)
  • 抽象要保持稳定

单例模式

迭代器模式

  • 集合接口,声明iterator()方法
  • 迭代器接口Iiterator,声明迭代器方法方法:next(),hasNext(),外界通过接口方法来访问集合
  • 具体迭代器类,对应于下面的具体集合类。该迭代器知道如何遍历集合。构造函数传入具体的集合对象
  • 具体集合类,实现集合接口,在iterator()方法中返回迭代器实例,并传入this实例。
  • 调用方使用集合iterator()方法获得迭代器实例,对集合进行遍历

适配器模式

实现方式1:

  • 声明外部需要使用的适配器接口
  • 适配器实现该接口,并从要适配的类继承
    实现方式2:
  • 声明外部使用的适配器接口
  • 适配器实现该接口,并使用适配对象实例完成操作

模版方法

  • 声明模版父类,需要子类实现的模版方法为抽象方法
  • 模版类把不可更改的主流程声明为final方法,避免子类复写
  • 子类继承模版父类,实现模板方法
  • 模版类的主流程、确定的流程方法使用final修饰,在一定程度上确保里氏替换原则。
  • 子类实现要符合里氏替换原则
  • 模版方法会让人理解困难,必须同时知道子类和父类在干什么

原型模式

  • 具体的产品类继承clone接口,实现clone方法
  • manager类实现管理复杂的,从clone方法生成的对象

桥接模式

  • 声明功能类的基本类,实现基本功能
  • 声明实现接口
  • 功能类通过构造函数或者set方法接受一个具体的实现类,该类实现实现接口
  • 具体功能不直接依赖于实现,而依赖实现接口
  • 添加功能时,继承原有的功能类,添加新功能方法即可
  • 需要不同实现时,给功能类注入不同实现对象

你可能感兴趣的:(设计模式)