设计模式笔记 0.面向对象设计模式与原则

 0.   面向对象设计模式与原则

面向对象的两个方向性思维——底层思维/抽象思维

向下，如何深入把握机器底层，从微观理解对象构造——底层思维

• 语言构造    • 编译转换    • 对象内存模型    • 运行机制    • ……

向上，如何将我们的周围世界抽象为程序代码——抽象思维

• 面向对象    • 组件封装    • 设计模式    • 架构模式    • ……

深入理解面向对象

向下：深入理解三大面向对象机制

封装，隐藏内部实现；继承，复用现有代码；多态，改写对象行为

向上：深刻把握面向对象机制所带来的抽象意义，理解如何使用这些机制来表达现实世界，掌握什么是“好的面向对象设计”

 

建筑商从来不会去想给一栋已建好的100层高的楼房底下再新修一个小地下室——这样做花费极大而且注定要失败。然而令人惊奇的是，软件系统的用户在要求作出类似改变时却不会仔细考虑，而且他们认为这只是需要简单编程的事。

——Object-Oriented Analysis and Design with Applications

Gof23种设计模式：历史性著作《设计模式：可复用面向对象软件的基础》一书中描述了23种经典面向对象设计模式，创立了模式在软件设计中的地位。该书四位作者被人们并称为Gang of Four （GoF），"四人组"，该书描述的23种经典设计模式又被人们称为Gof23 种设计模式。

Gof23种设计模式并不意味着它表示了所有的面向对象的设计模式。面向对象的设计模式也并不意味着代表所有的设计模式。Gof23种设计模式只是设计模式的基础。（面向对象设计模式是设计模式的子集。。。。）

我们在编程当中，都了解面向对象的语言的三大特性：封装、继承、多态。但是，仅仅通过面向对象的语言是不能够完全了解面向对象的设计的。面向对象语言的三大特性是为了实现面向对象而存在的，可以说面向对象是一篇文章，而三大特性是文章的写作技巧，这些写作技巧是为了写这篇文章而服务的。

复杂性的几个诱因

问题领域的复杂性——客户需求本身就很复杂，客户与开发人员互相不理解

管理开发过程的困难——开发是由人完成的，人的组织、潜能存在巨大复杂性

软件可能的灵活性——软件为开发人员提供了极大的灵活性，而开发人员也很容易滥用这种灵活性

表征离散系统行为的困难——软件系统本质上是一个离散系统，其复杂度要远远大于连续系统。一个简单的外部事件可能破坏整个系统。

软件设计复杂的根本原因

软件设计复杂性的根本原因在于：变化

客户需求的变化；技术平台的变化；开发团队的变化；市场环境的变化

如何解决复杂性？

分解——人们面对复杂性有一个常见的做法：即分而治之，将大问题分解为多个小问题，将复杂问题分解为多个简单问题。

抽象——更高层次来讲，人们处理复杂性有一个通用的技术，即抽象。由于不能掌握全部的复杂对象，我们选择忽视它的非本质细节，而去处理泛化和理想化了的对象模型。

两种分解与抽象方法

结构化程序设计——系统中的每个模块表示某个总体进程中的主要一步。

面向对象程序设计——根据问题域中的关键抽象来分解系统。

 

    //这里有一个Employee的抽象类，两个继承于Employee的派生类。GetSalary是一个抽象方法，这个方法的调用由派生类的类型决定。

    public abstract class Employee

    {

        public abstract int GetSalary();

    }

 

    public class Engineer : Employee

    {

        public override int GetSalary()

        {

            //......

            throw new NotImplementedException();

        }

    }

 

    public class Sales : Employee

    {

        public override int GetSalary()

        {

            //.....

            throw new NotImplementedException();

        }

    }

 

    //现在还有一个工厂类

    public class EmployeeFactory

    {

        public Employee GetEmployee(string EmployeeID)

        {

            Employee objEmp = null;

            switch (EmployeeID)

            {

                case "Engineer":

                    objEmp = new Engineer();

                    break;

                case "Sales":

                    objEmp = new Sales();

                    break;

            }

            return objEmp;

        }

    }

 

    //我们可以在程序种直接可以调用这个工厂类，来得到一个Employee

    static void Main()

    {

        EmployeeFactory objFactory = new EmployeeFactory();

        Employee objEmp = objFactory.GetEmployee("Sales");

        int Salary = objEmp.GetSalary();

    }

 

如果这时候，我们的Employee类型增加了一个Worker。那么我们只需要新增一个Worker类，并仅仅需要修改GetEmployee的内部实现，其他的我们可以不作任何修改。Engineer和Sales类也可以不用修改。那么就达到了一个松耦合的目的。这里我们GetEmployee的参数可以是别的类型，比如说枚举，或整形等。

 

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

从微观的层面来看面向对象的方式更强调各个类的"责任"，新增员工类型不会影响原来员工类型的实现代码。实际上就是对原有代码的扩展。

 

对象是什么？

从概念层面讲，对象是某种拥有责任的抽象。

从规格层面讲，对象是一系列可以被其他对象使用的公共接口。

从语言实现层面来看，对象封装了代码和数据。

 

面向对象的设计原则：

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

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

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

使用重构得到模式：设计模式的应用不宜先入为主，一上来就使用设计模式是对设计模式的最大误用。没有一步到位的设计模式。提倡Refactoringto Patterns。

 

几条更具体的原则：

单一职责原则(SRP)：一个类应该仅有一个引起它变化的原因。

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

Liskov 替换原则(LSP)：子类必须能够替换它们的基类。

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

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