程序设计原则

面向对象设计原则简介

设计原则就是架构设计的指导思想,它指导我们如何将数据和函数组织成类,如何将类链接起来成为组件和程序。反向来说,架构的主要工作就是将软件拆解成组件,设计原则指导我们如何拆解。拆解的粒度、组件间的依赖方向、组件解耦的方式等。

面向对象设计原则有很多,我们进行架构设计的主导原则是开闭原则(OCP)

在类和代码的层级伤有:

单一职责原则 SRP
里氏替换原则 LSP
接口隔离原则 ISP
依赖反转原则

在组件层级上有:

复用、发布等原则
共同闭包原则
共同复用原则

处理组件依赖问题的三原则:无依赖原则、稳定依赖原则、稳定抽象原则

设计原则

开闭原则(Open-Closed Principle, OCP)

设计好的软件应该易于扩展,同时抗拒修改。这里我们进行架构设计的主导原则。其他的原则都为这条原则服务。


一个软件实体应对扩展开放,对修改关闭
在设计一个模块时应当使这个模块可以在不被修改的情况下被扩展,即实现在不被修改源代码的情况下改变这个模块的行为。
为了满足开闭原则,需要对系统进行抽象化设计,抽象化是开闭原则的关键。在面向对象变成语言中,可以为系统定义一个相对稳定的抽象层,而将不同的实现行为在具体的实现层中完成。如果要修改系统的行为,无需对抽象层进行任何改动,只需要增加新的具体类来实现新的业务功能即可,实现在不修改已有代码的基础上扩展系统的功能,达到开闭原则的要求。
开闭原则还可以通过一个更具体的“对可变性封装原则”来描述,对可变性封装原则(Principle of Encapsulation of Variation, EVP)要求找到系统的可变性因素并将其封装起来。如将抽象层的不同实现封装到不同具体类中,而且EVP要求尽量不要将一种可变性和另一种可变性混合在一起,这将导致系统中的类的个数急剧增长,增加系统的复杂度。

以上部分摘自:https://blog.csdn.net/weixin_40216444/article/details/88120877

单一职责原则(Single responsibility principle SRP)


任何一个软件模块,都应该有且只有一个被修改的原因,“被修改原因”指系统的用户或所有者,说人话就是,任何模块只对一个用户的价值负责,该原则指定我们如何拆分组件。

不要存在多于一个导致类变更的原因
一个类、接口或方法只负责一项职责或职能
优点:
	降低类的复杂度;
	提高类的可读性,因为类的职能单一,看起来比较有目的性,显的简单;
	提高系统的可维护性,降低变更程序引起的风险。
缺点是如果一味追求单一职责,会导致类的数量非常多,你会发现,可以无限拆分下去。

上面摘自:https://blog.csdn.net/qq_24990561/article/details/87398385 上面网址中的例子,涉及到了其他的设计模式,我不举例子了,大概意思就是一个类,最好只有一个功能或者一类功能。

里氏替换原则 (Liskov substitution principle LSP)


当用统一接口的不同实现互相替换时,系统的行为应该保持不变,该原则指导的是接口与其实现方式。 我现在理解不透的就是这个原则,感觉很模糊,没有一个清晰的认识。

所有引用基类(父类)的地方必须能透明的使用其子类对象。
通俗的说就是,在软件中将一个基类对象替换成它的子类对象,程序不会产生任何错误和异常,反过来则不成立,如果一个软件实体使用的是一个子类对象的话,那么它不一定能够使用基类对象。例如:我喜欢动物,那我一定喜欢狗,因为狗是动物的子类;但是我喜欢狗,不能据此判定我喜欢动物,因为我可能不喜欢老鼠,虽然它是动物。

使用时注意: 子类的所有方法必须在父类中声明,或子类必须实现父类中声明的所有方法(比如PHP中接口)。根据里氏替换原则,为了曹正系统的扩展性,在程序中通常使用父类来进行定义。如果一个方法只存在子类中,在父类中不提供相应声明,则无法在以父类行的对象中使用该方法。 我们在运用里氏替换原则时,尽量把父类设计为抽象类或者接口,让子类继承或者实现它,并实现其定义的方法,运行时,子类实例替换父类实例,我们可以很方便地扩展系统的功能,同时无需修改原有子类的代码,增加新的功能可以通过增加一个新的子类来实现。里氏替换原则是开闭原则的具体实现手段之一。

上面摘自:https://www.cnblogs.com/cxks-xu/p/8554488.html 这里我理解出现了偏差,我把它和自动注入混在一起理解了。

接口隔离原则(Interface Segregation Principle)


不依赖不需要的方法、类或组件。该原则指导我们的接口设计。当我们依赖一个接口但只用到了其中的部分方法时,其实我们已经依赖了不需要的方法或者类。当这些方法或者类有变更时,会引起我们类的重新编译,或者引起我们组件的重新部署,这些都是不必要的。所以我们最好定义个小接口,把用到的方法拆出来。

我是PHP 这个说的很像 trait,使用它可以很好的拆分类的方法。

----------- 未完待续---------- 2019年10月18日 -------------续上------------- 2019年10月23日

依赖反转原则(Dependence Inversion Principle DIP)


依赖反转原则指一种特定的解耦(传统的依赖关系创建在高层次伤,而具体的策略设置则应用在低层次的模块上)形式,使得高层次的模块不依赖于低层次的模块的而实现细节,依赖关系被颠倒(倒置),从而使得低层次的模块的需求抽象。 跨越组建边界的依赖方向永远与控制流的方向相反,该原则知道我们设计组件间的依赖方向。 依赖反转原则是个可操作性非常强的原则,当你要修改组建的依赖方向时,将需要将进行组件间通信的类抽象为借口,接口放置在边界的那里,依赖就指向哪边。

复用、发布等同原则(Release Reuse Equivalency Principle REP)


软件复用的最小粒度应等同于其发布的最小粒度。直白地说,就是要复用一段代码就把他抽象成组件,这个原则,告诉我们怎么拆分组件及其粒度。

共同闭包原则(Common Closure Principle CCP)


为了相同的目的而同时修改的类,应该放在同一组件中。CCP原则是SRP()在组件层面的描述。我们可以根据这个原则来决定我们拆分组件的粒度。 对于大部分应用程序而言,可维护性的重要性远远大于可复用性,由同一原因引起的代码修改,最好在同一个组件中,如果分散在多个组件中,那么开发、提交、部署的成本都回上升。

共同复用原则(Common Reuse Principle CRP)


不要强迫一个组件依赖它不需要的东西。SRP原则是ISP原则在组件层面的描述。改原则指导我们组件的拆分的粒度。 相信你移动有这种经历,继承了组件A,但组件A依赖了组件B,C。即使组件B,C你完全用不到,也不得不集成进来。这时因为你只用到了组件A的部分能力,组件A中额外的能力带来了额外的依赖。如果遵循共同复用原则,你需要把A拆分,只保留要的部分。

一些总结


REP、CCP、CEP、三个原则之间存在彼此竞争关系,REP和CCP是粘合性原则,他们会让组件变的更大,而CRP原则是排除原则,它会让组件变小,遵守REP、CCP而忽略CRP,就会依赖了太多没有用到的组件和类,而这些组件或类的变动会导致你自己的组件进行太多不必要的发布;遵守REP、CRP而忽略CCP,会因为组件拆分太细了,一个需求变更可能要改n个组件,带来的成本也是巨大的。


抄录一遍对自己有不小的提升,虽然自己也知道一些原则,但是没有一个明确的定义,导致别人问的时候,按照自己的理解解释,而不会说一些名词,导致逼格的降低(....)。

阿杰博客
请先登录后发表评论
  • latest comments
  • 总共0条评论