一、单一职责原则。
Single Responsibility Principle,应该有且仅有一个原因引起类的变更,实际中比较不好把握,因为职责的划分没有一个统一的标准。
二、里氏替换原则。
Liskov Substitution Principle,通俗点讲,只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何错误或异常,使用者可能根本就不需要知道是父类还是子类。但是,反过来就不行了,有子类出现的地方,父类未必就能适应。
三、依赖倒置原则。
Dependence Inversion Principle,高层模块不应该依赖低层模块,两者都应该依赖其抽象;抽象
不应该依赖细节;细节应该依赖抽象;在Java语言中的表达就是,模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的;接口或抽象类不依赖于实现类;实现类依赖接口或抽象类。
四、接口隔离原则。
Interface Segregation Principle,建立单一接口,不要建立臃肿庞大的接口,接口尽量
细化,同时接口中的方法尽量少。(单一职责要求的是类和接口职责单一,注重的是职责,这是业务逻辑上的划分,而接口隔离原则要求接口的方法尽量少。例如一个接口的职责可能包含10个方法,这10个方法都放在一个接口中,并且提供给多个模块访问,各个模块按照规定的权限来访问,在系统外通过文档约束“不使用的方法不要访问”,按照单一职责原则是允许的,按照接口隔离原则是不允许的,因为它要求“尽量使用多个专门的接口”。)
五、迪米特原则。
Law of Demeter,一个对象应该对其他对象有最少的
了解。通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,你(被耦合或调用的类)的内部是如何复杂都和我没关系,那是你的事情,我就知道你提供的这么多public方法,我就调用这么多,其他的我一概不关心。
六、开闭原则。
Open Closed Principle,软件实体应该对扩展开放,对修改关闭,其含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化。
总结:
之所以有这么多的原则来指导我们进行程序的设计和开发,是因为我们的程序存在未知的改变。为了以最低的代价拥抱这种未知的变化,前辈们给我们总结了这么多原则,开闭原则应该是每一个大师的终极目标。在所有这些原则中,很重要的一环就是抽象类和接口的灵活运用。后面的23种具体的设计模式也是对“变化“的总结。
阅读(2006) | 评论(0) | 转发(0) |