设计模式在企业开发中的应用

1、2014年设计模式在企业开发中的应用设计模式在企业开发中的应用四川华迪信息技术有限公司四川华迪信息技术有限公司 2014年6月领先领先源源于专业，效果于专业，效果来自实力自实力主讲：张旺 高级软件工程师目标n 深刻理解面向对象思想n 理解面向对象的设计原则n 掌握常用的设计模式n 掌握设计模式的正确使用内容提要n 1 什么是面向对象n 2 面向对象的设计原则n 3 常用设计模式及其应用示例一、什么是面向对象n 1.1 面向对象的世界观n 1.2 面向对象的方法论n 1.3 面向对象的特征1.1 面向对象的世界观面向对象的基本哲学是认为世界是由各种各样具有自己的运动规律和内部状态的对象所组成的；

2、不同对象之间的相互作用和通讯构成了完整的现实世界。因此，人们应当按照现实世界这个本来面貌来理解世界，直接通过对象及其相互关系来反映世界。这样建立起来的系统才能符合现实世界的本来面目。1.2 面向对象的方法论面向对象的方法是面向对象的世界观在开发方法中的直接运用。它强调系统的结构应该直接与现实世界的结构相对应，应该围绕现实世界中的对象来构造系统，而不是围绕功能来构造系统。1.3 面向对象的特征n 封装n 继承n 多态1.3 面向对象的特征n 封装 每个对象都包含它能进行操作所需要的所有信息。这个特性被称为封装。因此对象不必依赖其他对象来完成自己的操作。 封装的好处 良好的封装能减少耦合。 类内部

3、的实现可以自由的修改。 类具有清晰的对外接口1.3 面向对象的特征n 继承 对象的继承代表了一种“is-a”的关系，如果两个对象A和B，可以描述为B是A，则表明B可以继承A。继承者还可以理解为是对被继承者的特殊化，因为它除了具备继承者的特性外，还具备自己独有的个性。 继承的特点 子类拥有父类非privite得属性和方法。 子类具有自己的属性和功能，即子类可以扩展父类没有的属性和功能。 子类还可以以自己的方式实现父类的功能（方法重写）1.3 面向对象的特征n 多态 多态表示不同的对象可以执行相同的动作。但需要通过他们自己的实现代码来执行。 使用多态需要注意 子类以父类的身份出现 子类在工作时以自

4、己的方式来实现 子类以父类的身份出现时，子类特有的属性和方法不可以使用。 为了使子类的实例完全接替来自父类的成员，父类必须将其成员声明为虚拟的（virtual)。 子类可以通过override来重写父类的方法。活字印刷面向对象n 为什么印刷术不是四大发明之一；而活字印刷是四大发明之一呢？2 面向对象的设计原则n 2.1 单一职责原则n 2.2 开放封闭原则n 2.3 依赖倒置原则n 2.4 Liskov替换原则n 2.5 接口隔离原则n 2.6 迪米特法则2.1 单一职责原则n 单一职责原则的核心思想为：一个类，最好只做一件事，只有一个引起它的变化。单一职责原则可以看做是低耦合、高内聚在面向对

5、象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而大大损伤其内聚性和耦合度。通常意义下的单一职责，就是指只有一种单一功能，不要为类实现过多的功能点，以保证实体只有一个引起它变化的原因。2.1 单一职责原则n 示例一、RBAC（基于角色的权限控制）应用设计n 示例二、电话示例IUserBoIUserBizUserBoUserBiz负责用户属性负责用户行为示例一示例二2.1 单一职责原则n 单一职责的好处 类的复杂性降低，实现什么职责都有清晰明确的定义 可读性提高，复杂性降低，那当然可读性提

6、高了 可维护性提高，那当然了，可读性提高，那当然更容易维护了 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大帮助2.2 开放封闭原则n 开放封闭原则的核心思想是：软件实体应该是可扩展的，而不是可修改的。也就是，对扩展开放，对修改封闭的。开放封闭原则主要体现在两个方面： 1、对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。 2、对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对其进行任何的修改。n 实现开放封闭原则的核心思想就是对抽象编程，而不对

7、具体编程，因为抽象相对稳定。让类依赖于固定的抽象，所以修改就是封闭的；而通过面向对象的继承和多态机制，又可以实现对抽象类的继承，通过覆写其方法来改变固有行为，实现新的拓展方法，所以就是开放的。n “需求总是变化”没有不变的软件，所以就需要用封闭开放原则来封闭变化满足需求，同时还能保持软件内部的封装体系稳定，不被需求的变化影响。2.2 开放封闭原则n 在做任何系统时，都不能指望需求在一开始就完全确定。怎样的设计才能面对需求的改变却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本呢？开放-封闭原则就是这个问题的答案。软件设计要容易维护又不容易出问题的最好方法就是多扩展、少修改n

8、绝对的对修改关闭是不可能的。无论模块是多么的“封闭”，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭作出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化2.2 开放封闭原则n 对修改封闭原则的应用示例/定义定义1 bool Connect(string userName, string password, string ftpAddress, int port); /定义2bool Connect(Account account); public class Account public string UserName

9、get; set; public string Password get; set; public string FtpAddress get; set; public string int Port get; set; 一般的设计原则强调方法参数尽量避免基本类型一般的设计原则强调方法参数尽量避免基本类型2.2 开放封闭原则n 对扩展开放的应用示例：排序2.3 依赖倒置原则n 依赖倒置原则的核心思想是：依赖于抽象。具体而言就是高层模块不依赖于底层模块，二者都同依赖于抽象；抽象不依赖于具体，具体依赖于抽象。n 依赖一定会存在于类与类、模块与模块之间。当两个模块之间存在紧密的耦合关系时，最好的方法

10、就是分离接口和实现：在依赖之间定义一个抽象的接口使得高层模块调用接口，而底层模块实现接口的定义，以此来有效控制耦合关系，达到依赖于抽象的设计目标。n 抽象的稳定性决定了系统的稳定性，因为抽象是不变的，依赖于抽象是面向对象设计的精髓，也是依赖倒置原则的核心。n 依赖于抽象是一个通用的原则，而某些时候依赖于细节则是在所难免的，必须权衡在抽象和具体之间的取舍，方法不是一层不变的。依赖于抽象，就是对接口编程，不要对实现编程。2.3 依赖倒置原则n 示例：一个拿C照的司机能够开Benz小车n 一个拿C照的司机能够开BMW小车n 一个拿A照的司机2.3 依赖倒置原则n 系统的三层架构示例2.4 Lisko

11、v替换原则n 里氏替换原则的核心思想是：子类必须能够替换其基类。这一思想体现为对继承机制的约束规范，只有子类能够替换基类时，才能保证系统在运行期内识别子类，这是保证继承复用的基础。在父类和子类的具体行为中，必须严格把握继承层次中的关系和特征，将基类替换为子类，程序的行为不会发生任何变化。同时，这一约束反过来则是不成立的，子类可以替换基类，但是基类不一定能替换子类。n Liskov替换原则，主要着眼于对抽象和多态建立在继承的基础上，因此只有遵循了Liskov替换原则，才能保证继承复用是可靠地。实现的方法是面向接口编程：将公共部分抽象为基类接口或抽象类，通过Extract Abstract Cla

12、ss，在子类中通过覆写父类的方法实现新的方式支持同样的职责。n Liskov替换原则是关于继承机制的设计原则，违反了Liskov替换原则就必然导致违反开放封闭原则。n Liskov替换原则能够保证系统具有良好的拓展性，同时实现基于多态的抽象机制，能够减少代码冗余，避免运行期的类型判别。2.4 Liskov替换原则n 里氏替换原则的经典问题： 正方形不是长方形 鸵鸟非鸟2.5 接口隔离原则n 接口隔离原则的核心思想是：使用多个小的专门的接口，而不要使用一个大的总接口。n 接口隔离原则体现在：接口应该是内聚的，应该避免“胖”接口。一个类对另外一个类的依赖应该建立在最小的接口上，不要强迫依赖不用的方

13、法，这是一种接口污染。n 接口隔离强调接口的单一性。而胖接口存在明显的弊端，会导致实现的类型必须完全实现接口的所有方法、属性等；而某些时候，实现类型并非需要所有的接口定义，在设计上这是“浪费”，而且在实施上这会带来潜在的问题，对胖接口的修改将导致一连串的客户端程序需要修改，有时候这是一种灾难。在这种情况下，将胖接口分解为多个特点的定制化方法，使得客户端仅仅依赖于它们的实际调用的方法，从而解除了客户端不会依赖于它们不用的方法。n 分离的手段主要有以下两种：1、委托分离，通过增加一个新的类型来委托客户的请求，隔离客户和接口的直接依赖，但是会增加系统的开销。2、多重继承分离，通过接口多继承来实现客户

14、的需求，这种方式是较好的。2.5 接口隔离原则2.5 接口隔离原则n 使用接口隔离原则应该要注意： 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。运用接口隔离原则，一定要适度2.6 迪米特法则n 迪米特法则（Law of Demeter）又叫作最少知识原则（Least Knowledge Princi

15、ple 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。英文简写为: LoD3 常用设计模式及其应用示例n 3.1 设计模式的分类n 3.2 单例模式n 3.3 简单工厂模式n 3.4 工厂模式n 3.5 策略模式n 3.6 代理模式n 3.7 观察者模式n 3.8 门面模式3.1 设计模式的分类n 创建型： 创建对象时，不再由我们直接实例化对象；而是根据特定场景，由程序来确定创建对象的方式，从而保证更大的性能、更好的架构优势。创建型模式主要有简单工厂模式（并不是23种设计模式之一）、工厂方法、抽象工厂模式、单例模式、生成器模式和原型模式。3.1 设计模式的分类n

16、结构型 用于帮助将多个对象组织成更大的结构。结构型模式主要有适配器模式、桥接模式、组合器模式、装饰器模式、门面模式、亨元模式和代理模式3.1 设计模式的分类n 行为性 用于帮助系统间各对象的通信，以及如何控制复杂系统中流程。行为型模式主要有命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板模式和访问者模式3.2 单例模式n 有些时候，允许自由创建某个类的实例没有意义，还可能造成系统性能下降。如果一个类始终只能创建一个实例，则这个类被称为单例类，这种模式就被称为单例模式。n 单例模式的特点 单例类只能有一个实例 单例类必须自己创建自己的唯一实例 单例类

17、必须给所有其它对象提供这一实例3.2 单例模式n 单例模式类图：3.2 单例模式n 单例模式的常见应用场景 Windows的Task Manager（任务管理器） windows的Recycle Bin（回收站） 网站的计数器，一般也是采用单例模式实现，否则难以同步 应用程序的日志应用，一般都何用单例模式实现，这一般是由于共享的日志文件一直处于打开状态，因为只能有一个实例去操作，否则内容不好追加 Web应用的配置对象的读取，一般也应用单例模式，这个是由于配置文件是共享的资源 HttpApplication 也是单位例的典型应用 3.2 单例模式n 一个单例模式应用的例子：常用的交流软件QQ，只

18、能打开一个与某个人聊天的窗口。3.2 单例模式n 单例模式应用场景： 资源共享的情况下，避免由于资源操作时导致的性能或损耗等 控制资源的情况下，方便资源之间的互相通信。如线程池等3.3 简单工厂模式n 经典问题：编写一个计算器，能够计算加减乘除运算。3.3 简单工厂模式n 从设计模式的类型上来说，简单工厂模式是属于创建型模式，又叫做静态工厂方法（Static Factory Method）模式，但不属于23种GOF设计模式之一。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式，可以理解为是不同工厂模式的一个特殊实现。3.3 简单工厂模式n

19、简单工厂模式包含的角色以及职责： 工厂（工厂（Creator）角色）角色：简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用，创建所需的产品对象。 抽象产品（抽象产品（Product）角色）角色：简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口 具体产品（具体产品（Concrete Product）角色）角色：是简单工厂模式的创建目标，所有创建的对象都是充当这个角色的某个具体类的实例。3.3 简单工厂模式n 简单工厂模式应用示例：聊天软件对信息的处理3.3 简单工厂模式n 简单工厂模式的优缺点： 优点：工厂类是整个模式的关键.包含了必要的逻辑判

20、断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的明确了各自的职责和权利，有利于整个软件体系结构的优化。3.3 简单工厂模式 缺点：由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。 当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模

21、块功能的蔓延，对系统的维护和扩展非常不利。3.3 简单工厂模式n 简单工厂模式的应用场景： 工厂类负责创建的对象比较少； 客户只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心； 由于简单工厂很容易违反高内聚责任分配原则，因此一般只在很简单的情况下应用。对于简单工厂模式的缺点，可以在工厂模式中得到克服3.4 工厂模式n 将计算器程序改为工厂模式实现。3.4 工厂模式n工厂模式的角色以及职责 抽象工厂（Factory）角色：是工厂方法模式的核心，与应用程序无关。任何在模式中创建的对象的工厂类必须实现这个接口。 具体工厂（Concrete Creator）角色：这是实现抽象工厂接口的具体工厂类

22、，包含与应用程序密切相关的逻辑，并且受到应用程序调用以创建产品对象。 抽象产品（Product）角色：工厂方法模式所创建的对象的超类型，也就是产品对象的共同父类或共同拥有的接口。 具体产品（Concrete Product）角色：这个角色实现了抽象产品角色所定义的接口。某具体产品有专门的具体工厂创建，它们之间往往一一对应。3.4 工厂模式n 工厂模式VS简单工厂 简单工厂最大的优点在于在工厂中存在必要的逻辑判断，可以根据客户端选择的条件动态的实例化相关的类。去除了客户端对具体产品的依赖。但是却违背了“开放-封闭”原则。 工厂模式在实现的时候，客户端需要决定实例化那一个类，选择判断的问题依旧存在

23、。但是工厂模式将简单工厂中在工厂中的判断放在了客户端来进行。3.4 工厂模式n 最佳实践：利用反射 利用反射可以去除客户端的逻辑判断3.5 策略模式n 案例：商场的会员卡制度。商场的会员卡有银卡，金卡，白金卡等级别。而不同的会员卡在消费时可以享受不同的折扣。3.5 策略模式n 策略模式用于封装系列的算法，这些算法通常被封装在一个被称为Context的类中，客户端程序可以自由选择其中一种算法，或让Context为客户端选择一种最佳算法使用策略模式的优势是为了支持算法的自由切换。3.5 策略模式3.5 策略模式n 策略模式的角色以及职责： 环境（Context）角色：持有一个Strategy类的引用。 抽象策略（Strategy）角色：这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。 具体策略（ConcreteStrategy）角色：包装了相关的算法或行为3.5 策略模式n 策略模式与简单工厂模式结合使用3.5 策略模式n 策略模式中使用反射3.6 代理模式n 代理模式是一种应用非常广泛的设计模式，当客户端代码需要调用某个对象时，客户端实际上不关心是否准确得到该对象，它只