设计模式在编程中有重要的指导意义,每个项目在架构阶段就应该很好的满足设计模式的六大原则,当然也要根据项目的实际情况来权衡取舍,平衡效率跟质量的关系。下面简单介绍下设计模式的六大原则。
1.单一职责原则
a)Single Responsibility Principle,简称SRP。这个原则是存在争议的,就是每个类的设计到底是“单一职责”还是尽可能的承担更多的“职责”?这个问题我觉得应该就项目的实际情况来决定,比如项目规模比较大,就应该把“职责”拆分的更细,这样可扩展性就会增加,同样的工作量会增加,在使用上可能需要的条件更多。简单的举个例子就:类的属性跟行为,如果分开,完成一件事情就要属性跟行为的不同接口结合到一起来实现,但是每个类的功能会很清晰。单一职责原则要求一个类只有一个原因引起是改变,我个人认为关于这个“尺度”其实可以根据实际情况来操作,可以是多于一个原因。
b)单一职责的好处有哪些呢?我们可以总结一下,不防结合上面“属性跟行为”的例子:
*类的复杂性降低了,实现什么职责都有清晰明确的定义(我只负责一件事)。
*可读性提高,这个是复杂性降低的必然结果。
*可维护性提高。
*变更引起的风险降低了,程序的变更是必不可少的,变更一个功能只需要修改一个接口就可,对其他的没有影响,对系统的稳定性、可扩展性、维护性都很大的帮助。
2.里氏代换原则
a)在面向对象的编程语言中,继承是必不可少的、非常优秀的语言机制。
优点是:
*代码共享,减少创建类的工作量,每个子类都拥有父类的方法用途属性。
*提高代码的重用性。
*子类形似父类又异于父类。
*提高代码的可扩展性,通过继承父类来扩展父类的功能。
*提高产品或者项目的开放性。
缺点:
*继承是侵入性的,只要是继承就必须拥有父类的所有属性与方法。
*降低代码的灵活性。
*增强了耦合性。
因为继承的这些有确定,下面我们引出解决方案:里氏代换原则,Liskov Substitution Principle。里氏代换原则为继承定义了一个规范,包含四层含义:
*子类必须完全实现父类的方法。
*子类可以有自己的个性。
*覆盖或者实现父类的方法时输入参数可以被放大。
*覆盖或者实现父类的方法时输出结果可以被缩小。
b)里氏代换原则的目的就是增强程序的健壮性,及时版本升级也可以保持良好的兼容性。
3.依赖倒置原则:
a)Dependence Inversion Principle。其原始定义包含三层含义:
*高层模块不应该一览底层模块,两者都应该依赖其抽象。
*抽象的不应该依赖细节。
*细节不应该依赖抽象。
具体在Java语言中的表现:
*模块间的依赖通过抽象发生,实现类之间不直接发生依赖关系,依赖通过接口或者抽象类来实现。
*接口或者抽象类不依赖实现类。
*实现类依赖接口或抽象类。
其实更加简洁的定义就是面向接口编程OOD(Object-Oriented
Design)的精髓之一。
4.接口隔离原则
a)接口隔离原则的定义:客户端不应该依赖其不需要的接口,类间的依赖关系应该建立在最小的接口上。简单理解就是,客户端应该以来其需要的接口,不需要的接口要剔除掉,也就是你依赖的接口的方法对于客户端来说应该是都有用的;最小的接口也就是要求接口细化,接口纯洁。b)接口隔离原则对接口进了规范约束:
*接口要尽量小,对于“小”也是有“尺度”的,需要自己把握。
*接口要高内聚,提高接口、类、模块的处理能力,减少对外的交互。
*定制服务,一个系统或者系统内的模块必然会有耦合,既然耦合,就要有相互访问的接口,所以设计时就需要为每个参与者定制服务。
*接口设计是有限度的,这个就是权衡接口的规模跟结构复杂度的关系,保证灵活性、开发难度、可维护性在接受的范围内。
5.迪米特法则
a)Law of Demeter,也称为最小知识原则(Least
Knowledge Principle):一个对象应该对其他对象有最少的只是了解。通俗的讲,一个类应该对自己需要耦合或者调用的类知道的最少。
b)迪米特法则对低耦合提出了明确的要求:
*只跟朋友交流,如果学过UML的话,应该知道,对象之间的耦合,存在组合、聚合、依赖等关系。
*朋友之间也有距离,具体的讲,一个类的public属性或方法越多,修改时涉及的问题就越多,变更引起的风险扩散也就越大。要将public的属性或者方法降到最低。
*是自己的就是自己的,如果一个方法在本类中接不增加类间关系,也对本类不产生负面影响,那就可以放置在本类中。
*谨慎使用Serializable,这个问题实际中出现很少,就是客户端与服务端通信是属性权限影响序列化的问题。
6.开闭原则
a)开闭原则是Java世界里最基础的设计原则,这指导我们如何建立一个稳定、灵活的系统。开闭原则的核心定:对扩展开放,对修改关闭。
b)开闭原则的重要性
*开闭原则对测试的影响,有变化时,原有健壮代码不修改,通过扩展实现变化,这样已经测试过的部分就不要再测试。
*开闭原则可以提高复用性
*开闭原则可以提高可维护性
*面向对象的要求。
c)开闭原则的实际使用:
*抽象约束,通过接口或抽象类约束一组可能变化的行为并能实现对扩展开放。
*元数据控制模块行为,元数据,metadata,也就是配置参数,这样可以减少重复开发,也就是很多参数可以是服务端提供的。
*定制项目章程,对于项目而言,约定由于配置。
*封装变化,将相同的变化封装到一个接口或者是抽象类中;将不同的变化封装到不同的接口或抽象类中。
PS:如有谬误欢迎指正!