2.3.1 Shape应用程序
下面的例子在许多讲述OOD的书中都提到过。它就是声名狼藉的“Shape”样例。它常常被用来展示多态的工作原理。不过，这次我们将它来阐明OCP。
我们有一个需要在舞台上绘制圆形和正方形的应用程序，圆和方形必须要按照特定的顺序绘制。我们将创建一个列表，列表由按照适当的顺序排列的圆和方形组成，程序遍历该列表，依次绘制每一个圆和正方形。
2.3.2 违反OCP样例
如果使用过程化方法并不采用OCP，我们也许会得到如下的解决方案。其中drawAllShapes函数会按照输入的图形序列分别调用对应图形类型的函数。（这里按照as3语法编写）
?drawAllShapes函数不符合OCP，因为它对于新的形状类型的添加不是封闭的。（举这个例子是希望大家可以看出明显的差别）如果希望这个函数能够绘制包含有三角函数的列表，就必须得更改这个函数。事实上，每增加一种新类型都要更新这个函数。
当然，这是一个简单而明显的例子。实际程序中，类似drawAllShapes中switch语句会在应用程序各个函数中重复出现，每个函数中switch语句负责完成的工作差别甚微。这些函数中，可能有负责拖扯形状对象的，有负责拉伸形状的。。。在这样的应用程序中增加一种新的形状类型，就意味这要找出所有包含上述switch的语句，并在每一处都增加新类型形状的判断。
这样的设计显然是糟糕的，不能接受的。它体现了程序的僵化性、脆弱性。
2.3.3 遵循OCP
以下程序展示了一个符合OCP的解决方案。在这个方案中我们编写了一个名为Shape的基类。这个抽象类仅有一个Draw抽象方法。circle和square都是它的派生类。
可以看出，如果我们想要扩展程序中DrawAllShape函数的行为，使之能够绘制一种新的形状，我们只需要增加一个新的shape的派生类。application的DrawAllShape函数不需要任何改变，这样就符合了OCP原则。无需更改自身代码，就可以扩展它的行为。
在实际应用中，Shape类可能会有更多方法，但是在应用程序中增加一种新的形状类依然非常简单。这个解决方案不再是脆弱的。同时也不是僵化的。{zh1}，这个方案也不再是牢固的。现在，任何程序中重用DrawAllShape时，都不需要附加Square和Circle。如果使用类库文件与主程序文件分离加载的方式，我们Flash程序的主程序甚至都不需要重新编译，只要重新编译类库文件就可以。
2.3.4是的，我说谎了
上面的例子其实不是{bfb}封闭的！如果我们要求所有的圆必须在正方形之前绘制，那么程序中DrawAllShape函数会怎样呢？DrawAllShape函数无法对这种变化做到封闭。要实现这个需求，我们需要修改DrawAllShape的实现，使它先扫描所有的圆，然后是正方形。

var gaJsHost = ((“https:” == document.location.protocol) ? “https://ssl.” : “http://www.”);
document.write(unescape(“%3Cscript src=’” + gaJsHost + “google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E”));

try {
var pageTracker = _gat._getTracker(“UA-12208106-2″);
pageTracker._trackPageview();
} catch(err) {}

动机：阅读《敏捷软件开发–原则、模式与实践》很长时间，收益非浅。不过书中的示例都是c++或者java的，想把他们改写成as的模式，同时增加一些自己的感想。
这条原则曾经被称之为内聚性(cohesion)。他们把内聚性定义为：一个模块的组合元素之间的功能相关性。在本章中，我们稍微改变一下它的含义,把内聚性和引起一个模块或者类改变的作用力联系起来。
1.单一职责原则（SRP）
就一个类而言，应该仅有一个引起它变化的原因。
例如，在一个Game类中，可能会具有两个不同的职责，一个职责是维护创建当前轮的比赛，另一个职责是计算总比赛得分。根据srp原则，着两个职责应该分离到两个类中，Game类保持维护创建当前轮的比赛，Scorer类负责计算比赛的得分。
如何要把这两个职责分离到单独的类中呢？因为每个职责都是一个变化的轴线。当需求变化时，该变化会反映到类的职责的变化。如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个。
如果一个类承担的职责过多，等于把这些职责耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。
例如，考虑下图的设计。Retangle类具有两方法，如图。一个方法把矩形绘制在屏幕上，另一个方法计算矩形的面积。

有两个不同的Application使用Rectangle类，如上图。一个是计算几何面积的，Rectangle类会在几何形状计算方面给予它帮助。另一个Application实质上是绘制一个在舞台上显示的矩形。
这一设计违反了单一职责原则。Rectangle类具有了两个职责，{dy}个职责是提供一个矩形形状几何数据模型；第二个职责是把矩形显示在屏幕上。
对于SRP的违反导致了一些严重的问题。首先，我们必须在计算几何应用程序中包含核心显示对象的模块。其次，如果绘制矩形Application发生改变，也可能导致计算矩形面积Application发生改变，导致不必要的重新编译，和不可预测的失败。
一个较好的设计是把这两个职责分离到下图所示的两个xx不同的类中。这个设计把Rectangle类中进行计算的部分一道GeometryRectangle类中。现在矩形绘制方式的改变不会对计算矩形面积的应用产生影响了。

1.1 什么是职责
在SRP中，我们把职责定义为“变化的原因”(a reason for change)。如果你能够想到多于一个的动机去改变类，那么这个类就具有多于一个的职责。有时，我们很难注意到这一点。我们习惯于以组的形式去考虑职责。
interface Modem{
???? public dial(pno:String):void;
??? ?public hangup():void;
???? public send(c:Char):void;
??? public recv():void;
}
上述Modem接口，大多数人会认为这个接口看起来非常合理。该接口声明了4个函数确实是Modem所具有的功能。然而，该接口却显示出了两个职责，一个是连接管理（dial+hangup），第二个是数据通信（send+recv）。
这两个职责应该被分离开么？这依赖于应用程序的变化。?是按照实际情况决定的。如果应用程序的变化会影响连接管理，那么设计就具有僵化的臭味。因为，调用send和recv的类必须要重新编辑。在这种情况下，这两个职责应该被分离，这样做会避免这两个职责耦合在一起。
另一方面，如果应用程序的变化总是导致这两方面职责同时变化，那么就不必分离他们。实际上，分离他们就会具有不必要的复杂性臭味。
1.2 持久化

上图展示了一种常见的违反SRP的情况，Employee类包含了业务逻辑和对于持久层的控制。这两个职责在大多数情况下决不应该混合在一起。业务规则往往会频繁的变化，而持久化的方式却不会如此频繁的变化，并且变化的原因也是xx不同的。把业务规则和持久模块绑定在一起的做法是不妥的。当僵化性和脆弱性的臭味变得强烈，那么就应该使用FACADE和PROXY模式对设计进行重构，分离这两个职责。
小结：
SRP是所有原则中最简单的之一，也是最难正确应用的。我们会自然的把职责结合在一起。软件设计要做的许多内容，就是发现职责并把那些职责相互分离。分离的原则也不是教条性的，需要应实际需求而定。

var gaJsHost = ((“https:” == document.location.protocol) ? “https://ssl.” : “http://www.”);
document.write(unescape(“%3Cscript src=’” + gaJsHost + “google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E”));

try {
var pageTracker = _gat._getTracker(“UA-12208106-2″);
pageTracker._trackPageview();
} catch(err) {}