常见的设计臭味和设计原则

在软件开发的过程中，常常有这样一种现象：起初我们对开发的系统架构非常清晰，但是随着开发的深入，或者因为功能的增加，或者因为需求的变更，我们可能逐渐偏离原来的设计并且发现开发工作很难进行下去。最后软件即使发生最细微的变化也会带来灾难性的后果，有人把这时的软件比作“坏面包”或者“坏鸡蛋”。它们都说明了一个共同的问题——腐化的软件设计，这时软件设计的臭味就表现出来了。

常见的软件设计中的臭味有：

1. 僵化性：软件难以修改。修改花费的代价巨大；
2. 脆弱性：一个修改可能引发很多意想不到的问题；
3. 顽固性：设计中包含了对其他系统有用的部分，但是把这部分从系统中分离出来所需要的努力和风险非常之大；
4. 粘滞性：当面临修改时，开发人员有两类修改方法：一是保持设计；而是破坏设计（拼凑方法。当可以保持系统设计的方法比破坏设计的方法更难应用时，系统就有很高的粘滞性；
5. 不必要的重复：是忽略抽象的结果；
6. 不必要的复杂性：系统包含了当前没有用的组成部分；
7. 晦涩性：模块难以理解，代码晦涩难懂。

软件为什么会腐化，简而言之就是因为没有遵循设计原则。经典的几种面向对象设计原则（不同于GOF设计模式）包括：SRP、OCP、LSP、DIP、ISP、LoD六种设计原则。下面分别进行详细介绍（附带实例）。

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

单一职责，简单地说即尽量让一个类的职责集中单一，如果它有多个职责应该把他们分出去。单一职责体现了“高内聚，低耦合”的理念。
假如有一个Server接口，如下图：

NO2 OCP（Opean Closed Principle）开放封闭原则

开放封闭原则的核心思想是：软件实体应该是可扩展，而不可修改的。也就是对扩展是开放的，而对修改是封闭的。
或许你会疑惑，认为这两个特征相互矛盾。因为扩展模块的常用方法就是修改模块的源代码。那么怎么样才能扩展模块的功能但是不去修改这个模块呢案在于“抽象”。实现开放-封闭的核心思想就是抽象编程而不是具体编程。让类依赖于固定的抽象体，对修改就是封闭的；通过面向对象的继承和多态可以实现对抽象体的继承，通过覆盖其方法来改变固有行为，实现新的扩展方法，所以对扩展是开放的。
场景：去银行办业务时，如果业务人员面对多种多样的客户需求，而且有很多人排在队伍中等待时，那么人们常常一等就是几十分钟甚至几个小时。因为业务人员要在不同的需求之间不断切换，电脑的界面也不断地切换。如下图：

接下来构造正方形Square类。

当设置了Square的宽时，它的长也会随着改变。同理设置长时宽也随之改变。
现在我们再考虑函数f，

如果传给f一个Rectangle（长宽不同）的对象，是没有问题的，但是如果传给一个Square对象问题就暴露了。因为正方形的宽是不会变的，这样就破坏了Square对象。
对于一般的数学思想而言，正方形可以看做是长方形，但是从程序设计的角度（行为方式上）来看，正方形决不是长方形。对象的行为方式才是软件真正关注的问题。Liskov替换原则清楚地指出，面向对象设计中的IS-A关系是就行为而言的，行为方式是可以合理假设的，是客户程序所依赖的。
Liskov原则让我们得出一个结论：一个模型如果孤立地看，并不具有真正意义上的有效性，模型的有效性只能通过它的客户程序来表现。
解决上述问题的方案是：用提取公共部分来代替继承。
即增加一个Quardrangle类，Square类和Rectangle类都继承它。Quardangle类中有长方形和正方形的公共方法。长方形和正方形中除了继承下来的公共方法外还可以添加各自的方法。UML图描述如下：

这样之后如果我们要添加一个新业务，只需要派生出相关的业务操作和用户即可。

NO5 ISP（Interface Segregation Principle）-接口分离原则

一个类对另外一个类应该表现成依赖尽可能小的接口。接口分离原则的核心是使用一个小的专门的接口而不是使用一个大的总接口。具体而言体现在两个方面：

1. 接口应该是内聚的，应该避免出现“胖”接口；
2. 一个类对另外一个类的依赖应该建立在最小的接口上，不要强迫依赖于不用的方法，这将导致接口污染。

关于ISP原则具体就不再展开。

NO6 LoD(Law of Demeter, LoD) -迪米特法则

一个对象应当对其他对象有尽可能少的了解
核心观念就是类间解耦——弱耦合
对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息

六大设计原则介绍：http://www.cnblogs.com/dolphin0520/p/3919839.html