一、理论知识
Software entities (classes, modules, function, etc.) should be open for extension, but closed for modification.
软件实体（模块，类，方法等）应该对扩展开放，对修改关闭。
开闭原则（OCP：Open-Closed Principle）是指在进行面向对象设计（OOD：Object Oriented Design）中，设计类或其他程序单位时，应该遵循：
- 对扩展开放（open）
- 对修改关闭（closed）
的设计原则。
开闭原则是判断面向对象设计是否正确的最基本的原理之一。
开放封闭原则（OCP，Open Closed Principle）是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化、降低耦合，而开放封闭原则正是对这一目标的最直接体现。其他的设计原则，很多时候是为实现这一目标服务的，例如以Liskov替换原则实现最佳的、正确的继承层次，就能保证不会违反开放封闭原则。
根据开闭原则，在设计一个软件系统模块（类，方法）的时候，应该可以在不修改原有的模块（修改关闭）的基础上，能扩展其功能（扩展开放）。
- 扩展开放：某模块的功能是可扩展的，则该模块是扩展开放的。软件系统的功能上的可扩展性要求模块是扩展开放的。
- 修改关闭：某模块被其他模块调用，如果该模块的源代码不允许修改，则该模块修改关闭的。软件系统的功能上的稳定性，持续性要求是修改关闭的。
这也是系统设计需要遵循开闭原则的原因：
1）稳定性。开闭原则要求扩展功能不修改原来的代码，这可以让软件系统在变化中保持稳定。
2）扩展性。开闭原则要求对扩展开放，通过扩展提供新的或改变原有的功能，让软件系统具有灵活的可扩展性。
遵循开闭原则的系统设计，可以让软件系统可复用，并且易于维护。
开闭原则的实现方法
为了满足开闭原则的 对修改关闭（closed for modification） 原则以及扩展开放（open for extension） 原则，应该对软件系统中的不变的部分加以抽象，在面向对象的设计中，
- 可以把这些不变的部分加以抽象成不变的接口，这些不变的接口可以应对未来的扩展；
- 接口的最小功能设计原则。根据这个原则，原有的接口要么可以应对未来的扩展；不足的部分可以通过定义新的接口来实现；
- 模块之间的调用通过抽象接口进行，这样即使实现层发生变化，也无需修改调用方的代码。
接口可以被复用，但接口的实现却不一定能被复用。接口是稳定的，关闭的，但接口的实现是可变的，开放的。可以通过对接口的不同实现以及类的继承行为等为系统增加新的或改变系统原来的功能，实现软件系统的柔软扩展。
简单地说，软件系统是否有良好的接口（抽象）设计是判断软件系统是否满足开闭原则的一种重要的判断基准。现在多把开闭原则等同于面向接口的软件设计。
开闭原则的相对性
软件系统的构建是一个需要不断重构的过程，在这个过程中，模块的功能抽象，模块与模块间的关系，都不会从一开始就非常清晰明了，所以构建100%满足开闭原则的软件系统是相当困难的，这就是开闭原则的相对性。但在设计过程中，通过对模块功能的抽象（接口定义），模块之间的关系的抽象（通过接口调用），抽象与实现的分离（面向接口的程序设计）等，可以尽量接近满足开闭原则。
二、应用举例
站在银行窗口焦急等待的用户，在长长的队伍面前显得无奈。所以，将这种无奈迁怒到银行的头上是理所当然的，因为银行业务的管理显然有不当之处。银行的业务人员面对蜂拥而至的客户需求，在排队等待的人们并非只有一种需求，有人存款、有人转账，也有人申购基金，繁忙的业务员来回在不同的需求中穿梭，手忙脚乱的寻找各种处理单据，电脑系统的功能模块也在不同的需求要求下来回切换，这就是一个发生在银行窗口内外的无奈场景。而我每次面对统一排队的叫号系统时，都为前面长长的等待人群而叫苦，从梳理银行业务员的职责来看，在管理上他们负责的业务过于繁多，将其对应为软件设计来实现，你可以将这种拙劣的设计表示如图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依然不能让人完全满意，银行业务还是以牺牲客户的选择为代价，难道不能提供一个自发组织客户寻找业务窗口的机制吗？但是这里的代码已经比最初好很多了。
四、规则建议
1、开放封闭原则，是最为重要的设计原则，Liskov替换原则和合成/聚合复用原则为开放封闭原则的实现提供保证。
2、可以通过Template Method模式和Strategy模式进行重构，实现对修改封闭、对扩展开放的设计思路。
3、封装变化，是实现开放封闭原则的重要手段，对于经常发生变化的状态一般将其封装为一个抽象，例如银行业务中的IBankProcess接口。
4、拒绝滥用抽象，只将经常变化的部分进行抽象，这种经验可以从设计模式的学习与应用中获得。
扫一扫
766
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
