面向对象设计模式与原则

示例场景：
设计一个人事管理系统，其中的一个功能是对各种不同类型
的员工，计算其当月的工资——不同类型的员工，拥有不同的薪金计
算制度。

结构化做法

  面向对象设计

1。根据不同的员工类型设计不同的类，并使这些类继承自一个
Employee抽象类，其中有一个抽象方法GetSalary。
2。在各个不同的员工类中，根据自己的薪金制度，重写（override）

1. enum EmployeeType
2. {                     
4. Engineer;                       
6. Sales;                          
8.   Manager;                       
10.    …… 
11.   } 
13. class Engineer: Employee{ 
14. ......
15.  public override int GetSalary() { 
16. .......
17. }
18. }
19.  // 显示工资程序 
20.  Employee e=  emFactory.GetEmployee(id);
21. MessageBox.Show( e.GetSalary()); 

 

果果将来需求改变了……

 随着客户公司业务规模的拓展，又出现了更多类型的员工，比如钟点
工、计件工……等等，这对人事管理系统提出了挑战——原有的程序
必须改变。

结构化做法

 几乎所有涉及到员工类型的地方（当然包括“计算工资程序”）都需要
 做改变……这些代码都需要重新编译，重新部署…….

 面向对象做法
 只需要在新的文件里增添新的员工类，让其继承自Employee抽象
 类，并重写GetSalary()方法，然后在EmployeeFactory.GetEmployee
 方法中根据相关条件，产生新的员工类型就可以了。其他地方（显示
 工资程序、Engineer类、Sales类等）则不需要做任何改变。

 

重新认识面向对象

*  对于前面的例子，从宏观层面来看，面向对象的构建方式更能适应软
   件的变化，能将变化所带来的影响减为最小

*  从微观层面来看，面向对象的方式更强调各个类的“责任”，新增员工
   类型不会影响原来员工类型的实现代码——这更符合真实的世界，也
   更能控制变化所影响的范围，毕竟Engineer类不应该为新增的“钟点
   工”来买单……

*  对象是什么？
    – 从概念层面讲，对象是某种拥有责任的抽象。
    – 从规格层面讲，对象是一系列可以被其他对象使用的公共接口。
    – 从语言实现层面来看，对象封装了代码和数据。

*  有了这些认识之后，怎样才能设计“好的面向对象”？
    – 遵循一定的面向对象设计原则
    – 熟悉一些典型的面向对象设计模式

从设计原则到设计模式

*  针对接口编程，而不是针对实现编程
    – 客户无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望
       的接口。

*  优先使用对象组合，而不是类继承
    – 类继承通常为“ 白箱复用”，对象组合通常为“黑箱复用”。继承在某种程度
       上破坏了封装性，子类父类耦合度高；而对象组合则只要求被组合的对
       象具有良好定义的接口，耦合度低。

*  封装变化点
    – 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行
       修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。

*  使用重构得到模式——设计模式的应用不宜先入为主，一上来就使用
   设计模式是对设计模式的最大误用。没有一步到位的设计模式。敏捷
   软件开发实践提倡的“Refactoring to Patterns”是目前普遍公认的最好
    的使用设计模式的方法。

 

几条更具体的设计原则

*   单一职责原则（SRP）：
     – 一个类应该仅有一个引起它变化的原因，

*   开放封闭原则（OCP）：
     – 类模块应该是可扩展的，但是不可修改（对扩展开放，对更改封闭）

*   Liskov 替换原则（LSP）:
     – 子类必须能够替换它们的基类

*   依赖倒置原则（DIP）：
     – 高层模块不应该依赖于低层模块，二者都应该依赖于抽象。【可以理解高层模块：显示工资的模块；低层模块：计算工资的模块】
     – 抽象不应该依赖于实现细节，实现细节应该依赖于抽象。

*  接口隔离原则（ISP）：
     – 不应该强迫客户程序依赖于它们不用的方法。