一、单一职责原则
Single Responsibility Principle,接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化。
二、里氏替换原则
Liskov Substitution Principle,通俗点讲,只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何错误或异常,使用者可能根本就不需要知道是父类还是子类。但是,反过来就不行了,有子类出现的地方,父类未必就能适应。
三、依赖倒置原则
Dependence Inversion Principle,高层模块不应该依赖低层模块,两者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象;在Java语言中的表达就是,模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的;接口或抽象类不依赖于实现类;实现类依赖接口或抽象类。
四、接口隔离原则
Interface Segregation Principle,这个原则的意思是:使用多个隔离的接口,比使用单个接口要好。还是一个降低类之间的耦合度的意思,从这儿我们看出,其实设计模式就是一个软件的设计思想,从大型软件架构出发,为了升级和维护方便。所以上文中多次出现:降低依赖,降低耦合。
五、迪米特原则
Law of Demeter,一个对象应该对其他对象有最少的了解。通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,你(被耦合或调用的类)的内部是如何复杂都和我没关系,那是你的事情,我就知道你提供的这么多public方法,我就调用这么多,其他的我一概不关心。
六、开闭原则
Open Closed Principle,软件实体应该对扩展开放,对修改关闭,其含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化。
总结:
之所以有这么多的原则来指导我们进行程序的设计和开发,是因为我们的程序存在未知的改变。为了以最低的代价拥抱这种未知的变化,前辈们给我们总结了这么多原则,开闭原则应该是每一个大师的终极目标。在所有这些原则中,很重要的一环就是抽象类和接口的灵活运用。后面的23种具体的设计模式也是对“变化“的总结。