开放封闭原则
开放封闭原则（OCP，Open Closed
Principle）是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化、降低耦合，而开放封闭原则正是对这一目标的最直接体现。其他的设
计原则，很多时候是为实现这一目标服务的，例如以Liskov替换原则实现最佳的、正确的继承层次，就能保证不会违反开放封闭原则。
关于开发封闭原则，其核心的思想是：
软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。
因此，开放封闭原则主要体现在两个方面：
对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。
对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。
“需求总是变化”、“世界上没有一个软件是不变的”，这些言论是对软件需求最经典的表白。从中透射出一个关键的意思就是，对于软件设计者来说，必须在不需要对原有的系统进行修改的情况下，实现灵活的系统扩展。而如何能做到这一点呢？
只有依赖于抽象。实现开放封闭的核心思想就是对抽象编程，而不对具体编程，因为抽象相对稳定。
让类依赖于固定的抽象，所以对修改就是封闭的；而通过面向对象的继承和对多态机制，可以实现对抽象体的继承，通过覆写其方法来改变固有行为，实现新的扩展
方法，所以对于扩展就是开放的。这是实施开放封闭原则的基本思路，同时这种机制是建立在两个基本的设计原则的基础上，这就是Liskov替换原则和合成/
聚合复用原则。关于这两个原则，我们在本书的其他部分都有相应的论述，在应用反思部分将有深入的讨论。
对于违反这一原则的类，必须进行重构来改善，常用于实现的设计模式主要有Template Method模式和Strategy模式。而封装变化，是实现这一原则的重要手段，将经常发生变化的状态封装为一个类。
应用反思
站在银行窗口焦急等待的用户，在长长的队伍面前显得无奈。所以，将这种无奈迁怒到银行的头上是
理所当然的，因为银行业务的管理显然有不当之处。银行的业务人员面对蜂拥而至的客户需求，在排队等待的人们并非只有一种需求，有人存款、有人转账，也有人
申购基金，繁忙的业务员来回在不同的需求中穿梭，手忙脚乱的寻找各种处理单据，电脑系统的功能模块也在不同的需求要求下来回切换，这就是一个发生在银行窗
口内外的无奈场景。而我每次面对统一排队的叫号系统时，都为前面长长的等待人群而叫苦，从梳理银行业务员的职责来看，在管理上他们负责的业务过于繁多，将
其对应为软件设计来实现，你可以将这种拙劣的设计表示如图1所示。
按照上述设计的思路，银行业务员要处理的工作，是以这种方式被实现的：
class BusyBankStaff
{
private BankProcess bankProc = new BankProcess();
// 定义银行员工的业务操作
public void HandleProcess(Client client)
{
switch (client.ClientType)
{
case "存款用户":
bankProc.Deposit();
break;
case "转账用户":
bankProc.Transfer();
break;
case "取款户":
bankProc.DrawMoney();
break;
}
}
}
这种设计和实际中的银行业务及其相似，每个BusyBankStaff（“繁忙的”业务员）接
受不同的客户要求，一阵手忙脚乱的选择处理不同的操作流程，就像示例代码中的实现的Switch规则，这种被动式的选择造成了大量的时间浪费，而且容易在
不同的流程中发生错误。同时，更为严重的是，再有新的业务增加时，你必须修改BankProcess中的业务方法，同时修改Switch增加新的业务，这
种方式显然破坏了原有的格局，以设计原则的术语来说就是：对修改是开放的。
以这种设计来应对不断变化的银行业务，工作人员只能变成BusyBankStaff了。分析这种僵化的代码，至少有以下几点值得关注：银行业务封装在一个
类中，违反单一职责原则；有新的业务需求发生时，必须通过修改现有代码来实现，违反了开放封闭原则。
解决上述麻烦的唯一办法是应用开放封闭原则：对扩展开放，对修改封闭。我们回到银行业务上看：
为什么这些业务不能做以适应的调整呢？每个业务员不必周旋在各种业务选项中，将存款、取款、转账、外汇等不同的业务分窗口进行，每个业务员快乐地专注于一
件或几件相关业务，就会轻松许多。综合应用单一职责原则来梳理银行业务处理流程，将职责进行有效的分离；而这样仍然没有解决业务自动处理的问题，你还是可
以闻到僵化的坏味道在系统中弥漫。
应用开发封闭原则，可以给我们更多的收获，首先将银行系统中最可能扩展的部分隔离出来，形成统
一的接口处理，在银行系统中最可能扩展的因素就是业务功能的增加或变更。对于业务流程应该将其作为可扩展的部分来实现，当有新的功能增加时，不需重新梳理
已经形成的业务接口，然后再整个系统要进行大的处理动作，那么怎么才能更好的实现耦合度和灵活性兼有的双重机制呢？
答案就是抽象。将业务功能抽象为接口，当业务员依赖于固定的抽象时，对于修改就是封闭的；而通过继承和多态机制，从抽象体派生出新的扩展实现，就是对扩展的开放。
依据开放封闭原则，进行重构，新的设计思路如图2所示。
图2 面向抽象的设计
按照上述设计实现，用细节表示为：
interface IBankProcess
{
void Process();
}
然后在隔离的接口上，对功能进行扩展，例如改造单一职责的示例将有如下的实现：
// 按银行按业务进行分类
class DepositProcess : IBankProcess
{
//IBankProcess Members
#region IBankProcess Members
public void Process()
{
// 办理存款业务
throw new Exception("The method or operation is not implemented.");
}
#endregion
}
class TransferProcess : IBankProcess
{
//IBankProcess Members
#region IBankProcess Members
public void Process()
{
// 办理转账业务
throw new Exception("The method or operation is not implemented.");
}
#endregion
}
class DrawMoneyProcess : IBankProcess
{
//IBankProcess Members
#region IBankProcess Members
public void Process()
{
// 办理取款业务
throw new Exception("The method or operation is not implemented.");
}
#endregion
}
这种思路的转换，会让复杂的问题变得简单明了，使系统各负其责，人人实惠。有了上述的重构，银行工作人员彻底变成一个EasyBankStaff（“轻松”的组织者）：
class EasyBankStaff
{
private IBankProcess bankProc = null;
public void HandleProcess(Client client)
{
bankProc = client.CreateProcess();
bankProc.Process();
}
}
银行业务可以像这样被自动地实现了：
class BankProcess
{
public static void Main()
{
EasyBankStaff bankStaff = new EasyBankStaff();
bankStaff.HandleProcess(new Client("转账用户"));
}
}
你看，现在一切都变得轻松自在，匆忙中办理业务的人们不会在长长的队伍面前一筹莫展，而业务员
也从繁琐复杂的劳动中解脱出来。当有新的业务增加时，银行经理不必为重新组织业务流程而担忧，你只需为新增的业务实现IBankProcess接口，系统
的其他部分将丝毫不受影响，办理新业务的客户会很容易找到受理新增业务的窗口，如图5所示。
图5符合OCP的设计
对应的实现为：
class FundProcess : IBankProcess
{
//IBankProcess Members
#region IBankProcess Members
public void Process()
{
// 办理基金业务
throw new Exception("The method or operation is not implemented.");
}
#endregion
}
可见，新的设计遵守了开放封闭原则，在需求增加时只需要向系统中加入新的功能实现类，而原有的一切保持封闭不变的状态，这就是基于抽象机制而实现的开放封闭式设计。
然而，细心观察上述实现你会发现一个非常致命的问题：人们是如何找到其想要处理的业务窗口，难
道银行还得需要一部分人力来进行疏导？然而确实如此，至少当前的设计必须如此，所以上述实现并非真正的业务处理面貌，实际上当前“轻松”的银行业务员，还
并非真正的“轻松”，我们忽略了这个业务系统中最重要的一部分，就是用户。当前，用户的定义被实现为：
class Client
{
private string ClientType;
public Client(string clientType)
{
ClientType = clientType;
}
public IBankProcess CreateProcess()
{
switch (ClientType)
{
case "存款用户":
return new DepositProcess();
break;
case "转账用户":
return new TransferProcess();
break;
case "取款用户":
return new DrawMoneyProcess();
break;
}
return null;
}
}
如果出现新增加的业务，你还必须在长长的分支语句中加入新的处理选项，switch的坏味道依然让每个人看起来都倒胃口，银行业务还是以牺牲客户的选择为代价，难道不能提供一个自发组织客户寻找业务窗口的机制吗？
其中的设计原则就是用于解决上述问题的。
规则建议
l 开放封闭原则，是最为重要的设计原则，Liskov替换原则和合成/聚合复用原则为开放封闭原则的实现提供保证。
l 可以通过Template Method模式和Strategy模式进行重构，实现对修改封闭、对扩展开放的设计思路。
l 封装变化，是实现开放封闭原则的重要手段，对于经常发生变化的状态一般将其封装为一个抽象，例如银行业务中的IBankProcess接口。
l 拒绝滥用抽象，只将经常变化的部分进行抽象，这种经验可以从设计模式的学习与应用中获得。
=================================================================================
ξ 4.1 什么是开闭原则
☆ 开闭原则指的是一个软件实体应对对扩展开发，对修改关闭(Software entities should be open for
extension, but closed for
modification)。这个原则是说在设计一个模块的时候，应对使这个模块可以在不被修改的前提下被扩展，换言之，应对可以不必修改源代码的情况下
改变这个模块的行为。
☆ 满足开闭原则的软件系统的优越性：
① 通过扩展已有的软件系统，可以提供新的行为，以满足对软件的新需求，使变化中的软件系统有一定的适应性和灵活性。
② 已有的软件模块，特别是最重要的抽象层模块不能再修改，这就使变化中的软件系统有一定的稳定性和延续性。
ξ4.2 实现开闭原则的关键
抽象化是解决问题的关键，在面向对象的编程语言里，可以给系统定义出一套相对较为固定的抽象设计，此设计允许无穷无尽的行为在实现层被实现。在语言里，可
以给出一个或多个抽象类或者接口，规定出所有的具体类必须提供的方法的特征作为系统设计的抽象层。这个抽象层预见了所有的可扩展性，因此，在任何扩展情况
下都不会改变。这就使得系统的抽象不需要修改，从而满足了开闭原则的第二条，对修改关闭。
同时，由于从抽象层导出一个或多个新的具体类可以改变系统的行为，因此系统的设计对扩展是开放的，这就满足了开闭原则的第一条。
☆ 对可变性的封装原则
这是对开闭原则的另外一种描述，它讲的是找到一个系统的可变因素，将之封装起来。该原则意味着两点:
① 一种可变性不应当散落在代码的很多角落，而应当封装到一个对象里面。继承应当被看做是封装变化的方法，而不应该被认为是一种从一般对象生成特殊对象的方法。
② 一种可变性不应当与另外一种可变性混合在一起。这意味着一般的继承层次不会超过两层。
关键知识点：
☆ 开闭原则的概念，软件实体对扩展开发，对修改关闭；
☆ 实现开闭原则的关键，利用接口或抽象类抽象出系统的抽象层，抽象层不变，利用实现层进行扩展；
☆ 对可变性的封装，将可变的元素封装起来，防止改变扩散到整个应用；
☆ 注意控制封装的粒度，不要将两种可变性封装到一起；
☆ 继承是用来封装可变性的，一般的继承层次不要超过两层；
☆ 策略模式是对开闭原则的很好诠释，其他还有工厂模式、建造模式、桥接模式、门面模式、调停者模式、访问者模式和迭代子模式等；
☆ 对“将条件转移语句改写成多态性”的重构行为应当遵循开闭原则，防止多态性污染；
☆ java下的单方法接口通常用来实现函数指针或者委托的功能；
☆ 任何一棵继承树都要以抽象类为根，具体类不是用来继承的，更不要从工具类继承；
☆ 抽象类要拥有尽可能多的共同代码，同时拥有尽可能少的数据。
☆
当Coad条件全部满足时，才应当考虑使用继承：派生类是基类的一个特殊种类，而不是其的一个角色，也就是说要区分“Has-a”和“Is-a”；永远不
会出现需要将派生类换成另外一个类的派生类的情况；派生类具有扩展基类的责任而不是具有置换或注销基类的责任；只有在分类学角度上有意义时，才可以使用继
承。
========================================================================
1. 不能修改该，但可以扩展的思想就是开闭原则
2. 软件实体（类、模块、函数等等）应该可以扩展，但是不可以修改。也就是对扩展开放，对更改关闭
3. 在面对需求的变更却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出先的版本
4. 多扩展，少修改。
5. 开闭原则的意思就是说，你设计的时候，时刻要考虑，尽量让这个类是足够好，写好了就不要去修改了，如果新需求来了，我们增加一些类就可以了，原来的代码能不动则不动。
6. 无论模块是多么的封闭，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对那些变化封闭做出选择，他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。
7. 在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化
8. 面对需求， 对程序的改动是通过增加新代码进行的，而不是更改现有的代码。
9. 在开发的工作进展不久就知道可能发生的变化，查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。
10.开放-封闭原则是面向对象设计的核心所在，遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分作出抽象，而对于应用程序中的每个部分都可以的进行抽象不是好办法，拒绝不成熟的抽象和抽象本身一样重要。
