设计模式之一:设计原则(转)
设计模式简介
设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。面向对象设计模式描述了面向对象设计过程中,特定场景下,类(抽象类之间,抽象类和派生类)之间或者相互通信的对象之间常见的组织关系。
对象是什么?
----从概念层面讲,对象是某种拥有责任的抽象。
----从规格层面讲,对象是一系列可以被其他对象使用的公共接口。
----从语言实现层面来看,对象封装了代码和数据
从设计原则到设计模式
针对接口编程,而不是针对实现编程
---- 客户无需知道所使用对象的特定类型,只需要知道对象拥有客户所期望的接口。
优先使用对象组合,而不是类继承
---- 类继承通常为“白箱复用”,对象组合通常为“黑箱复用”。继承在某种程度上破坏了封装性,子类和父类耦合度高;而对象组合则只要求被组合的对象具有良好定义的接口,耦合度低。
封装变化点
---- 使用封装来创建对象之间的分界层,让设计者可以在分界层的一侧进行修改,而不会对另一侧产生不良的影响,从而实现层次间的松耦合。
类设计的五项原则:
- SRP,单一职责原则,一个类应该有且只有一个改变的理由。
单一职责原则其实就是鼓励一个类只完成它的专属责任,它不因该完成多个任务或者代替其他类完成不应该完成的任务。当你有多个动机去想着改变这个类的时候,那么
这个类就违背的单一职责原则。
单一职责原则的好处是显而易见的,它可以帮我们实现低耦合这一基本原则。当我们需要改变一个功能时,我们只需要去寻找实现该功能的类即可,而不必担心改变该类
会引起其他的不可预知的错误。
-
OCP,开放封闭原则,应该能够不用修改原有类就能扩展一个类的行为。类模块应该是可扩展的,但是不可修改(对扩展开放,对修改封闭)。
-
LSP,里氏转换原则,派生类要与其基类自相容。子类必须能够替换它们的基类。
- DIP,依赖倒置原则,依赖于抽象而不是实现。高层模块不应该依赖于低层模块,二者都应该依赖于抽象。抽象不应该依赖于实现细节,实现细节应该依赖于抽象。
依赖倒转原则也可以理解成:要针对接口编程,不要针对实现编程。
- ISP,接口隔离原则,客户只要关注它们所需的接口。不应该强迫客户程序依赖于它们不用的方法。
设计模式融合了上述设计原则,并提供了对常见设计问题的解决方案核心。
OO基础
抽象,封装,多态,继承
其中,抽象和封装是OO的基本。抽象使实际概念得以升华并工程化,从而使设计者能够使用概念视角来考查和设计复杂系统。封装用于封装系统中的各种变化(点),如内部数据和子类差异等,从而简化系统编程。多态和继承则仅仅是实现抽象和封装的必要技术,并非OO本质。
OO原则(同于类设计的五项原则)
1) 封装变化:找出应用中可能的变化点,封装易变代码,隔离稳定代码。
2) 多用组合,少用继承
3) 针对接口编程,不针对实现编程
4) 为交互对象之间的松耦合设计而努力
5) 类应该对扩展开放,对修改关闭
6) 依赖抽象,不依赖具体类. 如工厂方法(Factory Method)
7) 只和朋友交谈(墨忒耳法则):在对象的方法内,只应该调用属于以下范围的方法:a) 该对象本身; b) 被当作方法的参数传递进来的对象; c) 此方法所创建或实例化的任何对象; d) 对象的任何组件(实例变量)。
8) 别找我,我会找你(依赖倒置原则)。父类对外提供公共接口,这些接口调用子类(底层)具体实现接口。这条原则需要通过抽象方法(钩子方法)实现,如模板方法,架构类。
9) 类应该只有一个改变的理由