单一职责原则

定义:

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

如果你能想到多余一个的动机去改变一个类,那么这个类就具有对于一个的职责,就应该考虑类的职责分离

职责过多的坏处

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

开发中

软件设计的重要部分,就是发现职责,并把职责相互分离

开放封闭原则

定义:

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

面对需求的变化,对程序的改动是通过增加新代码,而不是修改现有代码

何时应对变化

在编写代码时,假设变化不会发生,或者猜测可能发生的变化种类,当然猜测很难,因此当发生小变化时,想办法应对更大的变化,有变化立刻采取行动,创建抽象隔离以后发生的同类变化,达到可维护,可扩展,可复用的目的

依赖倒转原则

定义:

1.高层模块不应该依赖于低层模块,两者都依赖于抽象

2.抽象不应该依赖于细节,细节应该依赖于抽象

针对接口编程,不应该针对实现编程

例如: web开发中,业务层(高层)调用dao层(低层)访问数据库

里氏代换原则

定义:

子类型必须能够替换掉它们的父类型

在程序中,把父类型全部替换成子类型,程序的行为没有变化时,父类才能真正的被复用,而子类也能在父类的基础上增加新的行文

例如

生物学中,企鹅是鸟类,但是程序设计中,子类拥有父类所有非private的属性和行为,企鹅不能当做鸟类的子类,因为企鹅不能飞,

迪米特法则

定义:

如果两个类不必直接通信,那么这两个类就不应该发生直接的相互作用,如果一个类需要调用另一个类的方法时,可以通过第三者转发这个调用

强调类之间的耦合,类应当尽量降低成员的的访问权限,信息的隐藏促进了软件的复用

例如

小李第一天去公司上班, 需要找it部门的人安装电脑, 小李找人事, 人事给it部门的小王, 小王很忙没时间,人事又找到小赵, 最后是小赵帮忙安装电脑

由于it部门是抽象的,小李不需要认识it部门的人靠关系获得帮忙,即使it部门的员工换了也没事,小李只需通过人事转发就行了