分类 设计模式 下的文章

浅析设计模式-迪米特法则

迪米特法则的英文名称是 Low of Demeter,简称LoD。也称为最少知识原则(Least Knowledge Principle,LKP)

定义

一个对象应该对其它对象有最少的了解。通俗的讲,一个类应该对自己需要耦合或调用的类知道的最少,你(被耦合的类)的内部是如何的复杂都和我没关系,我只知道你提供的public方法,我就调用那么多,其它的一概不管。

含义

迪米特法则对类的低耦合提出了明确的要求,包含一下含义:

  • 只和朋友交流
  • 朋友间也是有距离的
  • 是自己的就是自己的
  • 谨慎使用Serializable

最佳实践

迪米特法则的核心观念就是类间解耦,弱耦合,只有弱耦合之后,类的复用率才可以提高,其要求的结果就是产生了大量的中转或跳转类,导致系统的复杂性提高,同时也为维护带来了难度,采用迪米特法则时需要反复权衡,既做到让结构清晰,又做到高内聚迪耦合。

浅析设计模式-接口隔离原则

接口隔离原则的英文名称是 Interface Segregation Principle,简称ISP。

定义

接口分为两种:

  • 实例接口(Object Interface),在Java中声明一个类,然后用new关键字产生一个实例,它是对一个类型的事物的描述,这是一种接口
  • 类接口(Class Interface), Java中经常使用的interface关键字定义的接口。

隔离有两种定义:

  • Clients should not be forced to depend upon interfaces that type don't use.(客户端不应该依赖它不需要的接口。)
  • The Dependency of one class to another one should depend on the smallest possible interface.(类间的依赖关系应该建立在最小的接口上)

可以把这两个定义概括为: 建立单一接口,不要建立臃肿庞大的接口。通俗一点:接口尽量细化,同时接口中的方法尽量少。

保持接口的纯洁性

接口隔离原则对接口进行规范约束,包含一下含义:

  1. 接口要尽量小
  2. 接口要高内聚
  3. 定制服务
  4. 接口设计是有限度的

最佳实践

  1. 一个接口只服务于一个子模块或业务逻辑
  2. 通过业务逻辑压缩接口中的public方法,接口时常去回顾,尽量让接口达到“满身筋骨肉”而不是“肥嘟嘟”的一大堆方法
  3. 已经被污染了的接口,尽量去修改,若变更的风险较大,则采用适配器模式进行转化处理
  4. 了解环境,拒绝盲从

浅析设计模式-依赖倒置原则

依赖倒置原则的英文名称是 Dependence Inversion Principle,简称DIP

定义

High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

- 阅读剩余部分 -

浅析设计模式-里氏替换原则

里氏替换原则的英文名称是 Liskov Subsitution Principle,简称 LSP。

定义

第一种定义,也是最正宗的定义: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is subsituted for o2 then S is a subtype T.(如果对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的所有程序P在所有的对象o1都代换为o2时,程序P的行为没有发生变化,那么类型S是类型T的子类型。)

第二种定义: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.(所有引用基类的地方必须能透明地使用其子类的对象)。

- 阅读剩余部分 -

浅析设计模式-单一职责原则

单一职责原则的英文名称是 Single Responsibility Principle,简称SRP。

定义

应该有且仅有一个原因引起类的变更。也就是说,一个类应当只有一个职责,如果类的职责过多,代码就会臃肿,可读性变差,也难以维护。单一职责原则和接口隔离原则有一定的关系,接口隔离之后,职责也就单一了,实现这个接口的类的职责自然也就单一了。但,接口隔离关注的是抽象层,单一职责关注的偏重于实现。

- 阅读剩余部分 -