面向对象设计（OOD）已经席卷计算机编程界N年之久，前辈们在编程的道路上坚信总一天，程序让生活简单，生活让编程淡然。经验汇集成了河流，河流汇成海洋。初涉面向对象当年确实难以接受抽象的思维，还好启蒙老师宰宰循循善诱，我才有不断的进步认识。最近听到哲姐给讲述设计模式，更是将几年的编程小经验有了新的升华。此前不没注意面向软件设计的基本原则框框，学习认识之后从前很多的阴霾逐渐豁然开朗，例如原来看Framework的架构定义，真是一塌糊涂 。闲言小叙，回归正本，软件设计七大原则是众多经验的荟萃，也如七把利剑一般指引同志们的构建方向，虽然程序不能总是嵌套条条框框，但是适时的利用也会产生柳暗花明的感觉。
每一个原则就是一把利剑，将抽象设计的思维推向普遍，在把普遍的结论总结为抽象的结果。下面从每一项简单的原则开始简要叙述我自己的认识。
单一职责原则---------SRP（Single Responsibility Principle ）
单一职责是每一个类应该只有一个职责，即应该仅有一个引起它变化的原因,如果你能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责。应该把多于的指责分离出去,分别再创建一些类来完成每一个职责。
例如：我写一个打飞机的小游戏，有一个关于飞机类，类中定义了飞机的飞行，开火，左右摇摆，而且又加入游戏的开始选择什么样的飞机。这显然是不合适的，一个飞机的类定义飞机的属性与动作，如果在管到登录，选择，就违反了单一职责的原则，是这个类显得臃肿不堪，难以后期维护，应该立即分离职责，用多个类实现。我们一定要注意，引起类变化的原因最好不要超过一个。
SRP中，把职责定义为“变化的原因”。如果你能想到N个动机去改变一个类，那么这个类就具有多于一个的职责。这里说的“变化的原因”，只有实际发生时才有意义。可能预测到会有多个原因引起这个类的变化，但这仅仅是预测，并没有真的发生，这个类仍可看做具有单一职责，不需要分离职责。如果分离，会带来不必要的复杂性。
再来看下一个类图是违反单一职责的例子，我觉得这是个很好的实例：
在这里，Rectangle类做了下面两件事：
· 计算矩形面积；
· 在界面上绘制矩形；
并且，有两个应用使用了Rectangle类：
· 计算几何应用程序用这个类计算面积；
· 图形程序用这个类在界面上绘制矩形；
再来看，Rectangle类做了两件事。在一个方法里它计算了面积 ：area（），在另外一个方法了它返回一个表示矩形的GUI ：draw（）。这会带来一些有趣的问题：
在计算几何应用程序中我们必须包含GUI。也就是在开发几何应用时，我们必须引用GUI库；
图形应用中Rectangle类的变化可能导致计算几何应用变化，编译和测试，反之亦然；
出现这样的情况该怎么样解决掉？拆分职责到两个不同的类中，如：
· Rectangle: 这个类应该定义area()方法；
· RectangleUI: 这个类应继承Rectangle类，并定义draw()方法。
在这里，Rectangle类被计算几何应用使用，而RectangleUI被图形应用使用。我们甚至可以分离这些类到两个独立的DLL中，那会允许我们在变化时不需要关心另一个就可以实现它。让每个方法只做某一项工作。那样允许你复用方法，并且一旦出现变化，你能购以修改最少的代码满足变化。