初读模式设计

 

从设计原则到设计模式

1. 针对接口编程,而不是针对实现编程

客户(客户程序)无需知道所使用对象的特定类型,只需要知道对象拥有客户所期望的接口

2. 优先使用对象组合,而不是类继承

类继承通常为”白箱复用”,对象组合通常为”黑箱复用”.继承在某种程序上破坏了封装性,子类你类耦合度高;而对象组合则只要求被组合的对象且有良好定义的接口,耦合度低.

不是说不用继承,如果在Is-a明显的情况下当然可以.Is-a:If A is a B,then A is B.

3. 封装变化点

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

4. 使用重构得到模式——设计模式的应用不宜先入为主

上来就使用设计模式是对设计模式的最大误用.没有一步到位的设计模式.敏捷软件开发实践提倡的”Refactoring to Patterns”是目前普遍公认的最好的使用设计模式的方法.

 

几条更具体的设计原则

1. 单一职责原则(SRP)

一个类应该仅有一个引起它变化的原因.

2. 开放封闭原则(OCP)

类模块应该是可扩展的,但是不可修改(对扩展开放,对更改封闭)

3. Liskov替换原则(LSR)

子类必须能够替换它们的基类

4. 依赖倒置原则(DIP)

高层模块不应该依赖于低层模块,二者都应该依赖于抽象.

抽象不应该依赖于实现细节,实现细节应该依赖于抽象.

5. 接口隔离原则(ISP)

不应该强迫客户程序依赖于它们不用的方法.

 

一般来说,高层模块它的更新速度是比较慢的,而低层模块它的更新速度是比较快的.

示例场景:

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

结构化做法:

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 Sales : Employee{

      …

      Public override int GetSalary(){

           …

      }

}

 

class Engineer : Employee{

      …

      public override int GetSlary(){

           …

      }

}

 

//显示工资程序

Employee e = emFactory.GetEmployee(id);

MessageBox,Show(e.GetSalary());

 

 

 

以上是两种做法,正常看不去没都可以,但是如果要新增一个员工类如钟点工,使用结构化做法的程序,要追加if else中程序片段,文件要重新编译,重新部署,其实算法也是变了,而面向对象做法保证了灵活度,只要新增一个钟点工类就可以实现,不需要改变内部算法.

就打个比方,如一个柜子,如果你要将其加上一个新的功能,如防火功能,则结构化的做法是把柜子砍了,把里头的内部结构改了,从中加入新的材料;而面向对象的方式就在柜子外部涂上一层防火涂料.

当然,如果需求不改变,就不要面向对象,结构化程序照样可以做得很好,需求定了,然后就从头到尾设计,只要保证算法正确,测试完成,交付给客户,这个单位就完成了,程序就永远可以跑了.也不需要修改.然而这样的程序是没有.所以我们要用面向对象程序设计.

源自:李建忠老师