面向对象中常见的设计原则

面向对象与设计模式的关系

自从GOF出了那本《设计模式》之后，再这四五年中，设计模式一词已经成了架构设计的代言，随后阎宏博士在中国道家思想与《建筑永恒之道》的基础之上，使用中国四大名著中的故事，为我们谱写了一本《Java与模式》，王永刚与王永武与为我们送来了一本《道法自然》更加为初学设计模式的朋友们带来了福音。

设计模式是在面向对象的基础之上，对软件的架构进行合理的组合，按照一定的原则“依赖倒置、李式代换、帝米特法则”使软件架构达到一种松散耦合、以求得对变化的适用。

所以设计模式的前提就是面向对象，其利用接口对模块进行隔离（门面模式、桥梁模式），利用多态对变化进行封装（策略模式、状态模式、装饰模式）、对创建进行合理规划（静态工厂模式、工厂模式、单例模式、多例模式）如果不能很好得掌握面向对象（OO）就更谈不上利用设计模式的成熟思想。

我们公司主要对国有大中企业的内部管理及物流状况进行开发，比如现在这个项目，是为一个政企不分的大型老国有企业，我们的开发建立在他们的体制改革基础之上，变化是常常发生的，因为他们的业务本身就在变化的过程中。

像这样的大型系统，如果不利用面向对象与设计模式的成熟思

想，很难对几百万行的代码进行控制。

在开发中，我们对于从业人员的要求必须得能看懂我做的UML图，设计中在关键点上我会采用适合设计模式：比如策略、门面、状态、工厂、装饰、桥梁...

而这些设计模式是建立在很强的OO思想之上的，如果对于OO都不能很好的掌握，更谈不上设计模式了。比如针对接口编成，多态性的应用，以及满足“李式代换、底米特法则等等”。如果不能用OO与设计模式的术语进行有效的沟通，那么对于项目的管理与技术沟通都是存在问题的。

在一些复杂的地方，如果一点点讲明是很麻烦并且很浪费时间的，如果说在这一个采用了“装饰模式”，假如对方能很快明白装饰模式是怎么一会儿事，那么他就可以快速的跟据UML图把这几个类做出来。

设计的基本原则

1. 单一职责

为何要把职责分离到单独的类中呢？

因为每个一个职责都是变化的一个轴线。当需求变化时，该变化会反映为类的职责变化。如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个。

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

缺点：类变多

2. 开发封闭原则

主要特征：

“对于扩展时开放的”（open for extension）

“对于更改是封闭的”（close for modificaiton）

做法1：实现抽象

发现变化，并且对可变性进行封装

做法2：针对接口（抽象）设计

由于子模块之间依赖一个固定的抽象，所以它对于更改可以是关闭的

3. 替换原则

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

4. 依赖倒置原则

高层模块不应该依赖于底层模块。两者都依赖于抽象。

抽象不应该依赖于细节。细节应该依赖于抽象。

依赖倒置原则是实现许多面向对象技术所宣称的好处的基本底层机制。如果程序的依赖关系是倒置的，它就是面向对象的设计。如果程序的依赖关系不是倒置的，它就是过程化设计

interfaceServerClient5. 接口隔离

不应该强迫客户依赖于它们不用的方法。

此原则是用来处理“胖”接口所具有的缺点。如果类的接口不是内聚的，就表示该类具有“胖”接口。

接口污染:将一些功能相近或功能相关的接口合并，并将这看成是代码优化的一部分。

结论：

胖类会导致它们客户程序之间产生不正常的并且有害的耦合关系。当一个客户程序要求该胖类进行一个改动时，会影响到所有其他客户的程序。因此，客户程序应该仅仅依赖于它们实际调用的方法。

通过对胖类的接口分解，可以解决客户程序和它们实际没用调用的方法间的依赖关系。

优秀设计实现-----发现变化并将其封装

优秀设计的精髓就是封装变化。就是将变化进行抽象，封装变化。这样才能保证软件的可扩展性以及模块之间的送耦合。

1 / 15 面向对象设计六大原则

面向对象设计的原则是面向对象思想的提炼，它比面向对象思想的核心要素更具可操作性，但与设计模式相比，却又更加的抽象，是设计精神要义的抽象概括。形象地将，面向对象思想像法理的精神，设计原则则相对于基本宪法，而设计模式就好比各式各样的具体法律条文了。

面向对象设计原则有6个：开放封闭原则，单一职责原则，依赖倒置原则，Liskov替换原则，迪米特法则和接口隔离原则或合成/聚合复用原则（不同资料略有不同，这里对7个都做了整理）。

1单一职责原则(Single Responsibility Principle SRP)

There should never be more than one reason for a class to change. 什么意思呢？

所谓单一职责原则就是一个类只负责一个职责，只有一个引起变化的原因。

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化会削弱或抑制这个类完成其他职责的能力，这个耦合会导致脆弱的设计。

软件设计真正要做的许多内容，就是发现职责并把这些职责相互分离；如果能够想到多于一个动机去改变一个类，那么这个类就具有多于一个职责，就应该考虑类的分离。

以调制解调器为例如下图：

从上述类图里面我们发现有四个方法Dial(拨通电话)，Hangup(挂电话)，Receive(收到信息)，Send(发送信息)，经过分析不难判断出，实际上Dial(拨通电话)和Hangup(挂电话)是属于连接的范畴，而Receive(收到信息)和Send(发送信息)是属于数据传送的范畴。这里类包括两个职责，显然违反了SRP。

这样做有潜在的隐患，如果要改变连接的方式，势必要修改Modem，而修改Modem类的结果导致凡事依赖Modem类可能都需要修改，这样就需要重新编译和部署，不管数据传输这部分是否需要修改。

因此要重构Modem类，从中抽象出两个接口，一个专门负责连接，另一个专门负责数据传送。依赖Modem类的元素要做相应的细化，根据职责的不同分别依赖不同的接口。如下图：

⾯向对象设计5⼤基本原则

⾯向对象设计模式有5⼤基本原则：单⼀职责原则、开发封闭原则、依赖倒置原则、接⼝隔离原则、Liskov替换原则。

1、单⼀职责原则(SRP)：

1.1，SRP(Single Responsibilities Principle)的定义：就⼀个类⽽⾔，应该仅有⼀个引起它变化的原因。简⽽⾔之，就是功能要单⼀。

1.2，如果⼀个类承担的职责过多，就等于把这些职责耦合在⼀起，⼀个职责的变化可能会削弱或者抑制这个类完成其它职责的能⼒。

这种耦合会导致脆弱的设计，当变化发⽣时，设计会遭受到意想不到的破坏。

1.3，软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。

⼩结：

单⼀职责原则可以看做是低耦合、⾼内聚在⾯向对象原则上的引申，将职责定义为引起变化的原因，以提⾼内聚性来减少引起变化的原因。

职责过多，可能引起它变化的原因就越多，这样导致职责依赖，相互之间就会产⽣原因，⼤⼤损伤其内聚性和耦合度。

2、开放-封闭原则(OCP)：

2.1，OCP(Open-Close Principle)的定义：就是说软件实体(类，⽅法等等)应该可以扩展，但是不能修改。它是软件设计中也是最重要

的⼀种设计原则。

2.2，OCP的两个特征：

2.2.1> 对于扩展是开放的。

2.2.2> 对于修改是封闭的。

2.3，什么时候应⽤OCP原则呢？

在我们最初编写代码时，假设变化不会发⽣，当变化发⽣时，我们就创建抽象(⽐如抽象类，接⼝等等)来隔离以后发⽣的同类变

化。

2.4，开放-封闭原则是⾯向对象设计的核⼼所在。遵循这个原则可以带来⾯向对象技术所声称的巨⼤好处，也就是可维护，可扩展，可复

⽤，灵活性好。开发⼈员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然⽽，对于应⽤程序中的每个部分都刻意地进⾏抽象同样不

是⼀个好主意。拒绝不成熟的抽象和抽象本⾝⼀样重要。

2.5，OCP的UML图：

⼩结：

开放封闭原则是⾯向对象设计的核⼼所在。遵循这个原则可以带来⾯向对象技术所声称的巨⼤好处：可维护、可扩展、可复⽤、灵活性好。