『设计模式』开发设计的七大原则,我做人还是挺有原则,那些代码呢?

2020-10-28 14:33:21 浏览数 (3)

设计模式的七大原则:

  1. 单一职责原则SRP(Single Responsibility Principle) 就一个类而言,应该仅有一个引起它变化的原因。
  2. 开放-关闭原则OCP(Open-CLosed Principle) 一个软件的实体应该对扩展开放,对修改关闭。
  3. 里氏代换原则(Liskov Substitution Principle) 子类型必须能够替换他们的基类(父类)。
  4. 依赖倒置原则DIP(Dependence Inversion Principle) 要依赖于抽象,不要依赖于具体。
  5. 最少知识原则LKP(Least Knowledge Principle)或称 迪米特法则(LoD) 一个类对于其他类知道的越少越好,就是说一个对象应当对其他对象有尽可能少的了解,只和朋友通信,不和陌生人说话
  6. 接口隔离原则(ISP) 使用多个专门的接口比使用单一的功能更多的总接口要好
  7. 合成/聚合原则 要尽量使用合成/聚合,而不是继承关系达到复用的目的
1.单一职责原则SRP(Single Responsibility Principle)

所谓单一职责原则就是一个类仅有一个引起它变化的原因。这里变化的原因就是所说的“职责”。如果一个类有多个引起它变化的原因,那么也就意味着这个类有多个职责,再进一步说,就是把多个职责耦合在一起了。

单一职责原则的核心就是控制类的粒度大小、将对象解祸、提高其内聚性,如果遵循单一职责原则将有以下优点:

  1. 降低类的复杂度。一个类只负责一项职责, 其逻辑肯定要比负责多项职责简单得多。
  2. 提高类的可读性。复杂性降低,自然其可读性会提高。
  3. 提高系统的可维护性。可读性提高,那自然更容易维护了。
  4. 变更引起的风险降低。变更是必然的,如果单一职责原则遵守得好, 当修改一个功能时,可以显著降低对其他功能的影响。
2.开放-关闭原则OCP(Open-CLosed Principle)
  • 所谓开放-闭合原则,指的是,一个类应该对扩展开放,最修改关闭。一般也被简称开闭原则,开闭原则是设计中非常核心的一个原则。
  • 开闭原则要求的是,类的行为是可以扩展的,而且是在不修改已有代码的情况下进行扩展,也不必改动已有的源代码或者二进制代码。
  • 实现开闭原则的关键就在于合理地抽象、分离出变化和不变化的部分,为变化的部分留下可扩展的方式,比如,钩子方法或者是动态组合对象等。
  • 这个原则看起来也很简单。但事实上,一个系统要全部做到遵守开闭原则,几乎是不可能的,也没这个必要。适度的抽象可以提高系统的灵活性,使其可扩展、可维护,但是过度的抽象,会大大的增加系统的复杂程度。应该在需要改变的地方应用开闭原则就可以了,而不用到处使用,从而陷入过度设计。

优点:

  1. 对软件测试的影响 软件遵守开闭原则的话,软件测试时只需要对扩展的代码进行测试就可以了,因为原有的测试 代码仍然能够正常运行。
  2. 可以提高代码的可复用性 粒度越小,被复用的可能性就越大; 在面向对象的程序设计中,根据原子和抽象编程可以提高 代码的可复用性。
  3. 可以提高软件的可维护性 遵守开闭原则的软件,其稳定性高和延续性强, 从而易于扩展和维护
3.里氏代换原则(Liskov Substitution Principle)

子类型(subtype)必须能够替换它们的基(父)类型。(子类可以以父类的身份出现)。 比如,如果是父类是鸟,鸟会飞。企鹅?不会飞,企鹅是鸟吗?所以企鹅不能继承鸟这个类。

  1. 里氏替换原则是实现开闭原则的重要方式之一。
  2. 它克服了继承中重写父类造成的可复用性变差的缺点。
  3. 它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误, 降低了代码出错的可能性。
4.依赖倒置原则DIP(Dependence Inversion Principle)

所谓依赖倒置原则,指的是,要依赖于抽象,不要依赖于具体类。要做到依赖倒置,典型的应用应该做到:

  • 高层模块不应该依赖于底层模块,二者都应该依赖于抽象
  • 抽象不应该依赖于具体实现,具体实现应该依赖于抽象
  • 一般高层模块包含对业务功能的处理和业务策略选择,应该被重用的,是高层模块去影响底层的具体实现。
  • 要针对接口编程,而不是针对实现编程

因此,这个底层的接口与应该由高层提出的,然后由底层实现的,也就是说底层接口的所有权在高层模块,因此是一种所有权的倒置。

启示:好的程序应该强内聚,松耦合。 优点:

  1. 依赖倒置原则可以降低类间的精合性。
  2. 依赖倒置原则可以提高系统的稳定性。
  3. 依赖倒置原则可以减少并行开发引起的风险。
  4. 依赖倒置原则可以提高代码的可读性和可维护性。
5.最少知识原则LKP(Least Knowledge Principle)或称 迪米特法则(LoD)

这个原则用来指导我们在设计系统的时候,应该尽量减少对象之间的交互,对象只和自己的朋友谈话,也就是只和自己的朋友交互,从而松散类之间的耦合。通过松散类之间的耦合来降低类之间的相互依赖,这样在修改系统的某一个部分的时候,就不会影响其他的部分,从而使得系统具有更好的维护性。

那么哪些对象才能当做朋友呢?

  • 当前对象本身
  • 通过方法的参数传递过来的对象
  • 当前对象所创建的对象
  • 当前对象的实例变量所引用的对象
  • 方法内所创建或者实例化的对象

其根本思想:

  • 强调了类之间的松耦合。
  • 类之间的耦合越弱,越有利于复用,一个处于弱耦合的类被修改,不会对有关系的类造成波及。
  • 信息的隐藏促进了软件的复用。

优点:

  • 降低了类之间的相合度, 提高了模块的相对独立性。
  • 由于相合度降低, 从而提高了类的可复用率和系统的扩展
6.接口隔离原则(ISP)

接口隔离原则(Interface Segregation Principle)讲的是:使用多个专门的接口比使用单一的总接口要好。换而言之,从一个客户类的角度来讲:一个类对另外一个类的依赖性应当是建立在最小接口上的。

过于臃肿的接口是对接口的污染。不提倡使用,也不应该是用Dirt- Interface。 接口隔离原则是为了约束接口、降低类对接口的依赖性,遵循接口隔离原则有以下优点:

  1. 将脏肿庞大的接口分解为多个粒度小的接口,可以预防外来变更的扩散, 提高系统的灵活性和可维护性。
  2. 接口隔离提高了系统的内聚性,减少了对外交互,降低了系统的藕合性。
  3. 如果接口的粒度大小定义合理, 能够保证系统的稳定性; 但是,如果定义过小,则会造成接口数量过多,使设计复杂化; 如果定义太大,灵活性降低,无法提供定制服务,给整体项目带来无法预料的风险。
  4. 使用多个专门的接口还能够体现对象的层次, 因为可以通过接口的继承, 实现对总接口的 定义。
  5. 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法,当实现这个接口的时候,被迫设计冗余的代码。
7.合成/聚合原则(Favor Composition Over Inheritance )

要尽量使用合成/聚合,而不是继承关系达到复用的目的。

合成/聚合原则就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过向这些对象的委派达到复用已有。

0 人点赞