(软件设计中的臭味.docxVIP

在软件开发的过程中，常常有这样一种现象：起初我们对开发的系统架构非常清晰，但是随着开发的深入，或者因为功能的增加，或者因为需求的变更，我们可能逐渐偏离原来的设计并且发现开发工作很难进行下去。最后软件即使发生最细微的变化也会带来灾难性的后果，有人把这时的软件比作“坏面包”或者“坏鸡蛋”。它们都说明了一个共同的问题——腐化的软件设计，这时软件设计的臭味就表现出来了。 常见的软件设计中的臭味有： 1.僵化性：软件难以修改。修改花费的代价巨大； 2.脆弱性：一个修改可能引发很多意想不到的问题； 3.顽固性：设计中包含了对其他系统有用的部分，但是把这部分从系统中分离出来所需要的努力和风险非常之大； 4.粘滞性：当面临修改时，开发人员有两类修改方法：一是保持设计；而是破坏设计（拼凑方法。当可以保持系统设计的方法比破坏设计的方法更难应用时，系统就有很高的粘滞性； 5.不必要的重复：是忽略抽象的结果； 6.不必要的复杂性：系统包含了当前没有用的组成部分； 7.晦涩性：模块难以理解，代码晦涩难懂。 软件为什么会腐化，简而言之就是因为没有遵循设计原则。经典的几种面向对象设计原则（不同于GOF设计模式）包括：SRP、OCP、LSP、DIP、ISP五种设计原则。下面分别进行详细介绍（附带实例）。NO1 SRP(Single Responsibility Principle)单一职责原则 单一职责，简单地说即尽量让一个类的职责集中单一，如果它有多个职责应该把他们分出去。单一职责体现了“高内聚，低耦合”的理念。 假如有一个Server接口，如下图：? 由UML图可以看出Server主要有两种职责，连接管理（建立和断开）和消息管理（发送和接收）。也许你会说这样的设计很合理啊，但是如果应用程序的变化影响到二者中的一个，就不得不都进行重新编译。所以我们必须把它们分离。如下图：NO2 OCP（Opean Closed Principle）开放封闭原则 开放封闭原则的核心思想是：软件实体应该是可扩展，而不可修改的。也就是对扩展是开放的，而对修改是封闭的。 或许你会疑惑，认为这两个特征相互矛盾。因为扩展模块的常用方法就是修改模块的源代码。那么怎么样才能扩展模块的功能但是不去修改这个模块呢？答案在于“抽象”。实现开放-封闭的核心思想就是抽象编程而不是具体编程。让类依赖于固定的抽象体，对修改就是封闭的；通过面向对象的继承和多态可以实现对抽象体的继承，通过覆盖其方法来改变固有行为，实现新的扩展方法，所以对扩展是开放的。 场景：去银行办业务时，如果业务人员面对多种多样的客户需求，而且有很多人排在队伍中等待时，那么人们常常一等就是几十分钟甚至几个小时。因为业务人员要在不同的需求之间不断切换，电脑的界面也不断地切换。如下图：对于BankHandle类我们可能有以下代码：/**银行业务员操作入口**/public class BankHandle{ //声明银行业务操作进程对象 private BankProcess bProc = new BankProcess(); //定义银行员工的业务操作 public void handleProcess(Client client){ switch(client.ClientType){ case 存款用户: bProc.deposit(); break; case 转账用户: bProc.transfer(); break; case 取款用户 bProc.drawmoney(); break; } }} 每个BankHandle对象接收不同客户的请求，并选择不同的操作流程处理（switch语句），这种被动式的选择浪费了很多时间。而且容易在不同的流程中发生错误。更糟的是，当添加新的业务时，必须修改BankProcess中的方法，同时还得修改switch增加新业务（即对修改是开放的）。 考虑OCP原则，我们将银行系统中最有可能扩展的部分分离出来，形成统一的接口处理。在银行系统中最有可能扩展的因素就是业务变更或者增加。我们应该将业务流程抽象为借口，而各种不同的业务只需要通过继承或者实现抽象出来的业务抽象体就可以了。这样既达到了对修改的封闭，也实现了对扩展的开放。 修改后的设计图如下： 有了上述抽象后，BankHandle类中代码就变得很精简了。如下：public class BankHandle{ private IBankProcess bProc = null; public void HandleProcess(){ bProc = client.createProcess(); bProc.process(); }} 这样当有新业务添加时你也应该知道该怎么办了吧？就不再赘述。NO3 LSP（Liskov Substitution