设计模式之七大原则

前言

  学习了这么长时间的设计模式,我们知道了设计模式是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。使用设计模式是为了代码可重用性、让代码更容易被他人理解、保证代码可靠性。俗话说:国有国法,家有家规,那在使用设计模式时都需要遵循什么原则呢?

内容

这里写图片描述

 单一职责原则

 What
  就一个类而言,应该仅有一个引起它变化的原因;

 Why
  如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏;

 How
  发现职责并把那些职责相互分离。如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个类的职责,就应该考虑类的职责分离;

 开放封闭原则

 What
  软件实体(类、模块、函数等)应该可以扩展,但是不可修改;

 Why
  面对需求的改变可以保持相对稳定,从而使系统可以在第一个版本以后不断推出新的版本;遵循该原则会使程序可维护,可扩展,可复用,灵活性好

 How
  无论模块是多么的“封闭”,都会存在一些无法对之封闭的变化。既然不可能完全封闭,设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类,然后构造抽象来隔离那些变化;当变化发生时,我们就创建抽象来隔离以后发生的同类变化,面对需求时,对程序的改动是通过增加新代码进行的,而不是更改现有的代码;

 依赖倒转原则

 What
  抽象不应该依赖细节,细节应该依赖抽象;针对接口编程,不要对实现编程;高层模块不应该依赖低层模块,两个都依赖抽象;

 Why
   面向对象的编程里强调强内聚,松耦合;CPU独自成为了产品,在千千万万的电脑主板上插上就可以使用,这是由于CPU的对外接口一样,这就是接口的最大好处;

 How
  谁也不要依靠谁,除了约定的接口,大家都可以灵活自如;只要接口是稳定的,那么任何一个更改都不用担心其他受到影响,使得无论高层模块还是低层模块都可以很容易地被复用;

 里氏代换原则

 What
  子类型必须能够替换掉他们的父类型;在软件里面,把父类都替换成他的子类,程序的行为没有变化;

 Why
   子类拥有父类所有非private的行为和属性,所以使继承复用成为了可能;由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展,使得开放-封闭成为了可能;

 How
  只有当子类可以替换掉父类,软件单位的功能不受到影响时,父类才能真正被复用,而子类也能够在父类的基础上增加新的行为;

 迪米特法则(最少知识原则)

 What
  如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用;

 Why
   迪米特法则的根本思想是强调了类之间的松耦合,类之间的耦合越弱,越有利于复用,一个处在弱耦合的类被修改,不会对有关系的类造成波及;

 How
  在类的结构设计上,每一个类都应当尽量降低成员的访问权限,一个类包装好自己的private状态,不需要让别的类知道自己的字段或者行为就不要公开;

 合成/聚合复用原则

 What
  在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过向这些对象的委派达到复用已有功能的目的;聚合表示一种弱的“拥有”关系,体现的是A对象包含B对象,但B对象不是A对象的一部分;合成则是一种强的“拥有”关系,体现了严格的部分和整体的关系,部分和整体的生命周期是一样的;

 Why
   让各个类尽可能少的跟别人联系,提高其扩展性和维护性;有助于保持每个类被封装,并被集中在单个任务上,保持较小规模;

 How
  尽量使用聚合,尽量不使用继承;

 接口隔离原则

 What
  每一个接口应该是一种角色,不多不少,不干不该干的事,该干的事都要干;一个类对另一个列的依赖应该建立在最小的接口上;

总结

  学习的过程中不要拘泥于一种形式,一种材料,应该集众家之所长,听取各方意见并进行研究。在使用设计模式的过程中,遵循设计模式的原则。

猜你喜欢

转载自blog.csdn.net/m0_37508531/article/details/80643075