《C#面向对象设计模式纵横谈》——1、面向对象设计模式与原则|第一讲

设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。

 

面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。

 

示例场景：

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

 

结构化做法
1。获得人事系统中所有可能的员工类型
2。根据不同的员工类型所对应的不同的薪金制度，计算其工资
enum EmployeeType{
Engineer;
Sales;
Manager;
…
}
// 计算工资程序
If ( type==EmployeeType.Engineer) {
……
}
else if (type== Employeetype.Sales) {
……
}

 

面向对象设计
1。根据不同的员工类型设计不同的类，并使这些类继承自一个Employee抽象类，其中有一个抽象方法GetSalary。
2。在各个不同的员工类中，根据自己的薪金制度，重写（override）GetSalary方法。
abstract class Employee{
…
public abstract int GetSalary();
}
class Engineer: Employee{
…
public override int GetSalary() {
……
}
}
class Sales: Employee{
…
public override int GetSalary() {
……
}
}
// 显示工资程序
Employee e=
emFactory.GetEmployee(id);
MessageBox.Show( e.GetSalary());

 

现在需求改变了……

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

 

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

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

 

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

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

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

 

从设计原则到设计模式

1、针对接口编程，而不是针对实现编程；

 

2、优先使用对象组合，而不是类继承；

 

3、封装变化点

 

使用重构得到模式！！！

 

几条更具体的设计原则

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

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

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

• 依赖倒置原则（DIP）：
– 高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
– 抽象不应该依赖于实现细节，实现细节应该依赖于抽象。

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