设计模式-可复用面向对象软件基础笔记

最新推荐文章于 2024-10-08 10:18:15 发布

weixin_34345560

最新推荐文章于 2024-10-08 10:18:15 发布

阅读量61

点赞数

文章标签：设计模式操作系统

原文链接：http://www.cnblogs.com/ctddjyds/p/5809181.html

版权

1.根据两条准则对设计模式进行分类：

第一是目的准则：模式依据其目的可分为创建型（Creational）、结构型 (Structural)、或行为型(Behavioral)三种。

创建型模式与对象的创建有关；

结构型模式处理类或对象的组合；

行为型模式对类或对象怎样交互和怎样分配职责进行描述。

第二是范围准则：指定模式主要是用于类还是用于对象。

类模式处理类和子类之间的关系，这些关系通过继承建立，是静态的，在编译时刻便确定下来了。

对象模式处理对象间的关系，这些关系在运行时刻是可以变化的，更具动态性。

从某种意义上来说，几乎所有模式都使用继承机制，所以“类模式”只指那些集中于处理类间关系的模式，而大部分模式都属于对象模式的范畴。

创建型类模式将对象的部分创建工作延迟到子类，而创建型对象模式则将它延迟到另一个对象中。

结构型类模式使用继承机制来组合类，而结构型对象模式则描述了对象的组装方式。

行为型类模式使用继承描述算法和控制流，而行为型对象模式则描述一组对象怎样协作完成单个对象所无法完成的任务。

2.一些导致重新设计的一般原因，以及解决这些问题的设计模式：
1) 通过显式地指定一个类来创建对象
在创建对象时指定类名将使你受特定实现的约束而不是特定接口的约束。这会使未来的变化更复杂。要避免这种情况，应该间接地创建对象。
设计模式：Abstract Factory(3.1)，Factory Method(3.3)，Prototype(3.4)。
2) 对特殊操作的依赖
当你为请求指定一个特殊的操作时，完成该请求的方式就固定下来了。为避免把请求代码写死，你将可以在编译时刻或运行时刻很方便地改变响应请求的方法。
设计模式：Chain of Resposibility(5.1)，Command(5.2)。
3) 对硬件和软件平台的依赖
外部的操作系统接口和应用编程接口 (API)在不同的软硬件平台上是不同的。依赖于特定平台的软件将很难移植到其他平台上，甚至都很难跟上本地平台的更新。所以设计系统时限制其平台相关性就很重要了。
设计模式：Abstract Factory(3.1)，Bridge(4.2)。
4) 对对象表示或实现的依赖
知道对象怎样表示、保存、定位或实现的客户在对象发生变化时可能也需要变化。对客户隐藏这些信息能阻止连锁变化。
设计模式：Abstract Factory(3.1)，Bridge(4.2)，Memento(5.6)，Proxy(4.7)
5) 算法依赖
算法在开发和复用时常常被扩展、优化和替代。依赖于某个特定算法的对象在算法发生变化时不得不变化。因此有可能发生变化的算法应该被孤立起来。
设计模式：Builder(3.2),Iterator(5.4)，Strategy(5.9)，Template Method(5.10)，Visitor(5.11)
6) 紧耦合
紧耦合的类很难独立地被复用，因为它们是互相依赖的。紧耦合产生单块的系统，要改变或删掉一个类，你必须理解和改变其他许多类。这样的系统是一个很难学习、移植和维护的密集体。
松散耦合提高了一个类本身被复用的可能性，并且系统更易于学习、移植、修改和扩展。设计模式使用抽象耦合和分层技术来提高系统的松散耦合性。
设计模式： Abstract Factory(3.1)，Command(5.2)，Facade(4.5)，Mediator(5.5)，Observer(5.7) ，Chain of Responsibility(5.1)。
7) 通过生成子类来扩充功能
通常很难通过定义子类来定制对象。每一个新类都有固定的实现开销(初始化、终止处理等)。定义子类还需要对父类有深入的了解。如，重定义一个操作可能需要重定义其他操作。一个被重定义的操作可能需要调用继承下来的操作。并且子类方法会导致类爆炸，因为即使对于一个简单的扩充，你也不得不引入许多新的子类。一般的对象组合技术和具体的委托技术，是继承之外组合对象行为的另一种灵活方法。新的功能可以通过以新的方式组合已有对象，而不是通过定义已存在类的子类的方式加到应用中去。另一方面，过多使用对象组合会使设计难于理解。许多设计模式产生的设计中，你可以定义一个子类，且将它的实例和已存在实例进行组合来引入定制的功能。
设计模式：Bridge(4.2)，Chain of Responsibility(5.1)，Composite(4.3)，Decorator(4.4)，Observer(5.7)，Strategy(5.9)。
8) 不能方便地对类进行修改
有时你不得不改变一个难以修改的类。也许你需要源代码而又没有(对于商业类库就有这种情况)，或者可能对类的任何改变会要求修改许多已存在的其他子类。设计模式提供在这些情况下对类进行修改的方法。
设计模式：Adapter(4.1)，Decorator(4.4)，Visitor(5.11)。

3.创建型模式

创建型模式抽象了实例化过程。它们帮助一个系统独立于如何创建、组合和表示它的那些对象。一个类创建型模式使用继承改变被实例化的类，而一个对象创建型模式将实例化委托给另一个对象。这些模式中有两个不断出现的主旋律。第一，它们都将关于该系统使用哪些具体的类的信息封装起来。第二，它们隐藏了这些类的实例是如何被创建和放在一起的。整个系统关于这些对象所知道的是由抽象类所定义的接口。

创建型模式在什么被创建，谁创建它，它是怎样被创建的，以及何时创建这些方面给予你很大的灵活性。它们允许你用结构和功能差别很大的“产品”对象配置一个系统。配置可以是静态的（即在编译时指定），也可以是动态的（在运行时）。

3.1 ABSTRACT FACTORY（抽象工厂）—对象创建型模式

3.2 BUILDER（生成器）—对象创建型模式

3.3 FACTORY METHOD（工厂方法）—对象创建型模式

3.4 PROTOTYPE（原型）—对象创建型模式

3.5 SINGLETON（单件）—对象创建型模式

4.结构型模式

4.4 DECORATOR（装饰）—对象结构型模式

5.行为型模式

5.2 COMMAND（命令）—对象行为型模式

5.7 OBSERVER（观察者）—对象行为型模式

5.9 STRATEGY(策略)—对象行为型模式