[设计模式] 开放封闭原则

2014/03/20 00:45
阅读数 189

开发封闭原则(Open-Closed Principle OCP)

Software entities(classes,modules,functions etc) should open for extension ,but close for modification.

   什么意思呢?

   所谓开放封闭原则就是软件实体应该对扩展开发,而对修改封闭。开放封闭原则是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化,降低耦合,而开放封闭原则正是对这一目标的最直接体现。

   开放封闭原则主要体现在两个方面:

   对扩展开放,意味着有新的需求或变化时,可以对现有代码进行扩展,以适应新的情况。

   对修改封闭,意味着类一旦设计完成,就可以独立其工作,而不要对类尽任何修改。

 

为什么要用到开放封闭原则呢?

软件需求总是变化的,世界上没有一个软件的是不变的,因此对软件设计人员来说,必须在不需要对原有系统进行修改的情况下,实现灵活的系统扩展。

 

如何做到对扩展开放,对修改封闭呢?

      实现开放封闭的核心思想就是对抽象编程,而不对具体编程,因为抽象相对稳定。让类依赖于固定的抽象,所以对修改就是封闭的;而通过面向对象的继承和多态机制,可以实现对抽象体的继承,通过覆写其方法来改变固有行为,实现新的扩展方法,所以对于扩展就是开放的。

      对于违反这一原则的类,必须通过重构来进行改善。常用于实现的设计模式主要有Template Method模式和Strategy 模式。而封装变化,是实现这一原则的重要手段,将经常变化的状态封装为一个类。

以银行业务员为例

没有实现OCP的设计:

01 public class BankProcess
02
03     {  //存款
04
05        public void Deposite(){}
06
07         //取款
08
09         public void Withdraw(){ }
10
11         //转账
12
13         public void Transfer(){}
14
15     }
16
17     public class BankStaff
18
19     {
20
21         private BankProcess bankpro = new BankProcess();
22
23         public void BankHandle(Client client)
24
25         {
26
27             switch (client.Type)
28
29             {  //存款
30
31                 case "deposite":
32
33                     bankpro.Deposite();
34
35                     break;
36
37                     //取款
38
39                 case "withdraw":
40
41                     bankpro.Withdraw();
42
43                     break;
44
45                     //转账
46
47                 case "transfer":
48
49                     bankpro.Transfer();
50
51                     break;
52
53             }
54
55         }
56
57     }

     这种设计显然是存在问题的,目前设计中就只有存款,取款和转账三个功能,将来如果业务增加了,比如增加申购基金功能,理财功能等,就必须要修改BankProcess业务类。我们分析上述设计就不能发现把不能业务封装在一个类里面,违反单一职责原则,而有新的需求发生,必须修改现有代码则违反了开放封闭原则。

      从开放封闭的角度来分析,在银行系统中最可能扩展的就是业务功能的增加或变更。对业务流程应该作为扩展的部分来实现。当有新的功能时,不需要再对现有业务进行重新梳理,然后再对系统做大的修改。

如何才能实现耦合度和灵活性兼得呢?

那就是抽象,将业务功能抽象为接口,当业务员依赖于固定的抽象时,对修改就是封闭的,而通过继承和多态继承,从抽象体中扩展出新的实现,就是对扩展的开放。

以下是符合OCP的设计:

首先声明一个业务处理接口

01 public  interface IBankProcess{  void Process();}
02
03 public class DepositProcess : IBankProcess
04
05     {
06
07         public void Process()
08
09         //办理存款业务
10
11             Console.WriteLine("Process Deposit");
12
13         }
14
15 }
16
17 public class WithDrawProcess : IBankProcess
18
19     {
20
21         public void Process()
22
23         //办理取款业务
24
25             Console.WriteLine("Process WithDraw");
26
27         }
28
29 }
30
31 public class TransferProcess : IBankProcess
32
33     {
34
35         public void Process()
36
37         //办理转账业务
38
39             Console.WriteLine("Process Transfer");
40
41         }
42
43     }
44
45 public class BankStaff
46
47     {
48
49         private IBankProcess bankpro = null;
50
51         public void BankHandle(Client client)
52
53         {
54
55             switch (client.Type)
56
57             {   //存款
58
59                 case "Deposit":
60
61                     userProc = new DepositUser();
62
63                     break;
64
65                     //转账
66
67                 case "Transfer":
68
69                     userProc = new TransferUser();
70
71                     break;
72
73                     //取款
74
75                 case "WithDraw":
76
77                     userProc = new WithDrawUser();
78
79                     break;
80
81             }
82
83             userProc.Process();
84
85         }
86
87     }

 

这样当业务变更时,只需要修改对应的业务实现类就可以,其他不相干的业务就不必修改。当业务增加,只需要增加业务的实现就可以了。

 

设计建议:

开放封闭原则,是最为重要的设计原则,Liskov替换原则和合成/聚合复用原则为开放封闭原则提供保证。

可以通过Template Method模式和Strategy模式进行重构,实现对修改封闭,对扩展开放的设计思路。

封装变化,是实现开放封闭原则的重要手段,对于经常发生变化的状态,一般将其封装为一个抽象,例如银行业务中IBankProcess接口。

拒绝滥用抽象,只将经常变化的部分进行抽象。


展开阅读全文
加载中

作者的其它热门文章

打赏
0
5 收藏
分享
打赏
0 评论
5 收藏
0
分享
返回顶部
顶部