面向对象设计模式与原则

2011/04/24 16:57
阅读数 222
                                                         面向对象设计模式与原则
1、设计模式简介
  1)每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心。
                ——Christopher Alexander
  2)设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。
  3)面向对象设计模式描述了面向对象设计过程中特定场景下,类与相互通信的对象之间常见的组织关系。

2、GoF 23种设计模式
  1)历史性著作《设计模式:可复用面向对象软件的基础》一书中描述了23种经典面向对象设计模式,创立了模式在软件中的地位。该书四位作者被人们并称为Gang of Four(GoF),“四人组”,该书描述的23种经曲典设计模式又被人们称为GoF23种设计模式。
  2)由于《设计模式:可复用面向对象软件的基础》一书确定了设计模式的地位,人们通常所说的设计模式隐含地表示“面向对象设计模式”。但这并不意味“设计模式”就等于“面向对象设计模式”,也不意味着GoF23种模式就表示了所有的“面向对象设计模式”。除了“面向对象设计模式”外,还有其他设计模式。除了GoF 23种设计模式外,还有更多的面向对象设计模式。
  3)GoF 23种设计模式是学习面向对象设计模式的起点,而非终点。

3、设计模式与面向对象
  1)面向对象设计模式解决的是“类与相互通信的对象之间的组织关系,包括它们的角色、职责、协作方式几个方面”。
  2)面向对象设计模式是:“好的面向对象设计”,所谓:“好的面向对象设计”是那些可以满足“应对变化,提高复用”的设计。
  3)面向对象设计模式的是软件设计,因此它是独立于编程语言的,但是面向对象设计模式的最终实现仍然要使用面向对象编程语言来表达。
  4)面向对象设计模式不像算法技巧,可以照搬照用,它是建立在对“面向对象”纯熟、深入的理解的基础上的经验性认识。掌握面向地象设计模式的前提是首先掌握“面向对象”!

4、OOPL并非面向对象的全部
  1)通过面向对象编程语言(OOPL)认识的面向对象,并不是面向对象的全部,甚至只是浅陋的面向对象。
  2)OOPL的三大机制“封装、继承、多态”可以表达面向对象的所有概念,但这三大机制本身并 没有刻画出面向对象的核心精神。换言之,既可以用这三大机制做出“好的面向对象设计”,也可用这三大机制做出“差的面向对象设计”。不是使用了面向对象的语言(例如C#),就实现了面向对象的设计与开发!因此我们不能依赖编程语言的面向对象机制,来掌握面向对象。
  3)OOPL没有回答面向对象的根本性问题——我们为什么要使用面向对象?我们应该怎样使用 三大机制来实现“好的面向对象”?我们应该遵循什么样的面向对象原则?
  4)任何一个严肃的面向对象程序员(例如C#程序员),都需要系统地学习面向对象的知识,单纯从编程语言上获得的面向对象知识,不能够用任面向对象设计与开发。

5、从一个示例谈起
  1)示例场景:
  我们需要设计一个人事管理系统,其中的一个功能是对各种不同类型的员工,计算其当月的工资——不同类型的员工,拥有不同的薪金计算制度。
  2)结构化做法
    A:获得人事系统中所有可能的员工类型
    B:根据不同的员工类型所对应的不同的薪金制度,计算其工资
  enum EmployeeType{
    Engineer; // 软件工程师
    Sales;    // 销售人员
    Manager; // 管理人员
    ...
  }
  //计算工资程序
  if (type == EmployeeType.Engineer){
    ......
  }
  else if (type == EmployeeType.Sales){
    ......
  }
    变化点:如果加入员工,在计算工资程序中需要加入elas if,这样做引起了

这个类的变化
  3)面向对象设计
    A:根据不同的员工类型设计不同的类,并使这些类继承自一个Employee抽象类,其中有一个抽象方法GetSqlary。
    B:在各个不同的员工类中,根据自己的薪金制度,得写(override)

GetSqlary方法
  abstract class Employee{
    ......
    public abstract int GetSalary();
  }
  class Sales : Employee{
    ......
    public override int GetSalary(){
      ......
    }
  }
  class Engineer : Employee{
    ......
    public override int GetSalary(){
      ......
    }
  }
  class Manager : Employee{
    ......
    public override int GetSalary(){
      ......
    }
  }
  ......
 
  //显示工资程序
  Employee e = emFactory.GetEmployee(id);
  MessageBox.Show(e.GetSalary());
    需求变化,程序不可能不会改变,但我们要做的是降度改变,减少改变的影响
  4)现在需求改变了...
      随着客户公司业务规模的拓展,又出现了更多类型的员工,比如钟点工、计件工......等等,这对人事管理系统提出了挑战——原有的程序必须改变。
      A:结构化的做法
  几乎所有涉及到员工类型的地方(当然包括“计算工资程序”)都需要做改变......这些代码都需要重新编译,重新部署......
      B:面向对象做法
  只需要在新的文件里增添新的员工类,让其继承自Employee抽象类,并重写GetSalary()方法,然后在EmployeeFactory.GetEmployee()方法中根据相关条件,产生新的员工类型就可以了。其他地方(显示工资程序、Engineer类、Sales类等)则不需要做任何改变。

6、重新认识面向对象
  1)对于前面的例子,从宏观层面来看,面向对象的构建方式更适应软件的变化,能将变化带来的影响减小。
  2)从微观层面来看,面向对象的方式更强调各个类的“责任”,新增员工类型不会影响原来员工类型的实现代码——这更符合真实的世界,也更能控制变化影响的范围,毕竟Engineer类不应该为新增“钟点工”来买单.....
  3)对象是什么?
    A:从概念层面计,对象是某种拥有责任的抽象。
    B:从规格层面计,对象是一系列可以被其他对象使用的公共接口。
    C:从语言实现层面来看,对象封装了代码和数据。
  4)有了这些认识之后,怎样才能设计“好的面向对象”?
    A:遵循一定的面向对象设计原则
    B:熟悉一些典型的面向对象设计模式

7、从设计原则到设计模式
  1)针对接口编程,而不是针对实现编程
  客户(客户程序)无需知道所使用对象的特定类型,只需知道对象拥有客户所期望的接口。
  2)优先使用对象组合,而不是类继承
  类继承通常为“白箱复用”,对象组合通常为“黑箱复用”。继承在某种程度上破坏了封装性,子类父类耦合度高;而对象组合则只要求被组合的对象具有良好定义的接口,耦合度低。
  3)封装普变化点
  使用封装来创建对象之间的分界层,让设计者可以在分界层的一侧进行修改,而不会对另一侧产生不良的影响,从而实现层次间的松耦合。
  4)使用重构得到模式——设计模式的应用不宜先入为主,一上来就使用设计模式是对设计模式的最大误用。没有一步到位的设模式。敏捷软件开发实践提倡的“Refactoring to Patterns”是目前普遍公认的最好的使用设计模式的方法。

8、几条更具体的设计原则
  1)单一职责原则(SRP):
  一个类应该公有一个引起它变化的原因。
  2)开放封闭原则(OOP):
  类模块应该是可护展的,但是不可修改(对扩展开放,对更改封闭)。
  3)Liskov替换原则(LSP):
  子类必须能够替换它们的基类。
  4)依赖倒置原则(DIP):
  A:高层模块不应该依赖于低层模块,二者都应该依赖于抽象。
  B:抽象不应该依赖实现细节,实现细节应该依赖于抽象。
  5)接口隔离原则(ISP):
  不应该强迫客户程序依赖于它们不用的方法。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
6 收藏
0
分享
返回顶部
顶部