in Software engineering 设计模式 ~ read.

【设计模式】三大原则


单一职责原则

一个类而言,应该仅有一个引起它变化的原因
SRP
如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其它职责能力。这种耦合会导制脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏。

软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离;判断能够分离的方式,就是如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责,就应该考虑类的职责分离

开放封闭原则

对于扩展是开放的,对于修改是封闭的。
ASD
无论模块是多么封闭,都会存在一些无法对之封闭的变化。既然不可能完全封闭,设计人员需要对他设计的模块应该对哪种变化封闭做出选择,必须猜测出最有可能发生的变化种类,然后构造抽象隔离这些变化。

在最初写代码时,假设变化不会发生,当变化发生时,就建立抽象类来隔离以后发生的同类变化。

精神: 面对需求,对程序的改动是通过增加新代码进行的,而不是改变现有代码。

拒绝不成熟的抽象,过犹不及。

依赖倒转原则

抽象不应该依赖细节,细节应该依赖抽象。即,要针对接口编程,不应该针对实现编程。
reseve
reseveUML

里氏代换原则

一个软件实体,如果使用的是一个父类的话,那么一定适用于其子类,而且察觉不出父类对象和子类对象的区别。即,在软件里,把父类替换成子类,程序的行为没有变化。
LSP

迪米特法则

也叫最少知识原则,强调的是在类的结构设计上,每个类都应当尽量降低成员的访问权限(private) ,强调了类之间的松耦合
LOB