[设计模式原则]开闭原则(Open

ycycoco

　　对扩展开放，对修改关闭（设计模式的核心原则）
　　设计模式重在设计阶段，封装变化点，预留扩展。而不是在需求变化时再来讨论类的继承扩展组合修改等等。
　　用抽象构建框架，用实现扩展细节。
　　框架在设计阶段就确认，细节在后期变化修改进行扩展。
　　在设计阶段就考虑好变化点，把变化点抽象并封装，把整个框架骨骼搭起来。后期需求变化的时候，扩展抽象的变化点，对现有框架骨骼不会造成影响。
　　其他五个原则丰满了开闭原则
　　单一职责原则告诉我们实现类要职责单一；-〉类
　　里氏替换原则告诉我们不要破坏继承体系；-〉类和父类
　　迪米特法则告诉我们要降低耦合；-〉类和世界类
　　依赖倒置原则告诉我们要面向接口编程；-〉类和接口
　　接口隔离原则告诉我们在设计接口的时候要精简单一；-〉接口
　　
　　常用于实现的设计模式主要有Template Method模式和Strategy模式。
　　
　　假设是银行处理流程，针对不同客户，假定银行是这么处理的
　　代码一：



class BusyBankStaff
{
private BankProcess bankProc = new BankProcess();
public void HandleProcess(Client client)
{
switch (client.ClientType)
{
case "存款用户":
bankProc.Deposit();
break;case "取款用户":
bankProc.DrawMoney();
break;
}
}
}
　　
　　其实这么写完全没问题
　　语法没问题
　　效率也挺好的
　　老师也是这么教的
　　问题来源于变化。
　　程序在客户眼里是一个个界面
　　底层代码架构对于客户毫无意义，就像01010101010101对于你我毫无意义
　　如果客户没有新的需求，跟客户说变更架构带来的好处，同样毫无意义
　　意义在于，变更界面，添加界面，以及这些变更所需要的时间
　　对的，时间
　　时间是金钱
　　大家都在跟时间赛跑
　　有人说时间是个假像
　　因为时间不存在
　　但是时间是金钱
　　现在，客户有需求了，
　　第一个需求，要添加一个界面，一天后使用，一般情况很好解决，程序员无敌，分分钟搞定
　　第二个需求，不能对现有系统现有功能造成影响，这个没人能够确定，比如，蝴蝶效应，程序是一个世界，模块是一个世界，类是一个世界。需求，改变了规则，世界会对此作出反应。客户希望世界添加新的元素，比如，有吸血鬼的存在。客户的要求很简单，这个世界要出现吸血鬼。这是唯一的需求，可是程序员不要简单认为这是唯一的需求。我们应该认识到，这个世界不能因为出现吸血鬼而出现越来越多的吸血鬼，然后过了几天，客户将看到一个除了吸血鬼没有别的存在的世界？这不是我们想要的。吸血鬼的存在不能对现有世界造成太大的影响，他们也需要遵守既定世界的规则，并维持既定世界的既定运行模式。
　　回到银行这个问题
　　现在需求增加一个用户用于 转账用户，如果代码一是原始代码，那么如下修改，红色为新增业务
　　代码二：



class BusyBankStaff
{
private BankProcess bankProc = new BankProcess();
public void HandleProcess(Client client)
{
switch (client.ClientType)
{
case "存款用户":
bankProc.Deposit();
break;
case "取款用户":
bankProc.DrawMoney();
break;
case "转账用户":
bankProc.Transfer();
break;
}
}
}

class BankProcess
{
public static void Main()
{
BusyBankStaff bankStaff = new BusyBankStaff();
bankStaff.HandleProcess(new Client("转账用户"));
}
}
　　
　　这么写完全没有问题
　　不过我们注意到，修改代码在方法HandleProcess里，HandleProcess在类BusyBankStaff里。
　　或者这么说
　　你改变了HandleProcess这个小世界，也就是改变了BusyBankStaff这个世界，然后，外面还有别的模块等等越来越大的世界。
　　如果HandleProcess是个独立的世界，或者如果HandleProcess是个封装完整良好的方法，那么不需要考虑改变对其余世界带来的影响，同时有单元测试来保证这个小世界本身的稳定。
　　如果这个方法封装的不够好，修改波及到了类的其余部分，那么至少，这个类要封装的够好才能保证对类外面的世界影响够小，
　　如果这个类封装的不够好，修改波及到了别的类，那么至少，这个模块要封装的够好才能。。。扒拉扒拉
　　你看，改变，往往不是一件简单的事情
　　聪明的人才能看到改变并不可怕，可怕的是不受控制的改变
　　时刻把改变造成的影响控制在尽可能小的范围内，这样才能快速增加新的需求（开发需要花时间），快速测量改变造成的影响（测试需要花时间），如果造成影响也可快速修复（修复需要花时间），这在软件升级中很重要。开闭原则，保证改变影响的范围尽可能小，这才是重点。
　　直接附上开闭原则的设计
　　代码三：



interface IBankProcess
{
void Process();
}
class DepositProcess : IBankProcess
{
public void Process()
{
// 办理存款业务
throw new Exception("The method or operation is not implemented.");
}
}
class DrawMoneyProcess : IBankProcess
{
public void Process()
{
// 办理取款业务
throw new Exception("The method or operation is not implemented.");
}
}
class EasyBankStaff
{
private IBankProcess bankProc = null;
public void HandleProcess(Client client)
{
bankProc = ProcessFactory.CreateProcess(client);
bankProc.Process();
}
}
class BankProcess
{
public static void Main()
{
EasyBankStaff bankStaff = new EasyBankStaff();
bankStaff.HandleProcess(new Client("转账用户"));
}
}
　　
　　对比代码二和代码三，业务处理分散到三个类中
　　当变化发生时，代码三需要的改动是新增转账业务类实现IBankProcess，在客户段传入转账用户。因为是新类，对现有业务类不造成影响。变化紧紧局限在新的小世界里。开发和测试都可以很快地进行。
　　
　　参考：
　　开放封闭原则
　　设计模式六大原则（6）：开闭原则