设计模式怎样解决设计问题

1、寻找合适的对象。注意点：客户请求是使对象执行操作的唯一方法，操作又是对象改变内部数据的唯一方法。

由于这些限制，对象的内部状态是被封装的，它不能被直接访问，它的表示对于对象外部是不可见的。

以前只知道对象是封装的，为什么被封装，却只知其一不知其二，今天终于知道了。

2、决定对象的粒度。设计模式很好的讲述了这个问题

3、指定对象的接口。在面向对象系统中，接口是基本的组成部分。对象只有通过它们的接口才能与外部交流，如果不通过

对象的接口就无法知道对象的任何事情，也无法请求对象做任何事情。

当给对象发送请求时，所引起的具体操作既与请求本身有关又与接受对象有关。支持相同请求的不同对象可能对请求激发

的操作有不同的实现。发送给对象的请求和它的相应的操作在运行时刻的连接就称之为dynamic binding(动态绑定).也就

是说发送的请求直到运行时刻才受你的具体的实现的约束。进一步说，动态绑定允许你在运行时刻彼此替换有相同接口的

对象。这种可替换性就称为polymorphism(多态)。终于对多态有了更进一步的了解，以前对于多态只是停留在概念上，

没有对它有更加深刻的了解，这次终于有了清晰的理解。

4、描述对象的实现。对象的实现是有它的类决定的，类指定了对象的内部数据和表示，也定义了对象所能完成的操作。

可复用的面向对象设计的一个重要原则就是：针对接口编程，而不是针对实现编程。回想最近一段时间的代码编程好像

都是面向实现的编程，复用性很不好，这也造成了在以后的编程过程中若出现同样功能要求时，只能复制代码而无法重

用以前写过的代码。这样功能模块的可复用性就非常的不好。因此针对接口编程是非常重要的，当然可能第一次编写可

以复用的模块时，可能要花费一些时间，但却给后期的开发带极大的方便，所以说多花一点时间来设计代码还是很必要

的，毕竟开发是一种脑力劳动而非体力劳动。

5、运用复用机制。面向对象系统中功能复用的两种常用技术是类继承和对象组合(object composition).

类继承通常被称为white-box reuse(白箱复用)。术语"白箱"是相对可视性而言，在继承方式中，父类的内部细节对

子类可见，这好像有点违背面向对象中的封装性这一特性。

对象组合式类继承外的另一种复用选择。新的更复杂的功能可以通过组装或组合对象来获得。对象组合要求被组合的对

象具有良好定义的接口。这种复用风格被称为black-box reuse(黑箱复用),因为对象的内部细节是不可见。这就导出了

面向对象设计的第二个原则：优先使用对象组合，而不是继承。

这使我想到了Eclipse插件。如果你需要Eclipse具有什么样的功能，就可以下载什么样的插件。按需索取，这就避免了因为一些不必要的

功能而影响到了系统的整体性能。当然容器的开发是至关重要的，它必须有很好的兼用性，要考虑许多因素。这也是我

想到了一些应用系统就是应用了插件开发的思想，需要系统具有那些功能，就选用相应的功能插件，这样开发的话就大

大缩短了开发周期，大大增加了公司的竞争力。

委托(delegation)是一种组合方法，它使组合具有与继承同样的复用能力，在委托方式下，有两个对象参与处理一个请

求，接受请求的对象将操作委托给它的代理者(delegate).使用继承时，被继承的操作总能引用接受请求的对象，C++

中通过this成员变量，Smalltalk中通过self.本来我以为只有C#中有委托的概念，看来其他语言中也有啊，Java也有

啊。看来委托并不是C#所独有的特性啊。委托的不足：动态的、高度参数化的软件比静态软件更难于理解。还有运行

低效问题。只有当委托使设计比较简单而不是更复杂时，它才是好的选择。

6、关联运行时刻和编译时刻的结构。一个面向对象程序运行时刻的结构通常与它的代码结构相差较大。代码结构在编

译时刻就被确定下来了，它有继承关系固定的类组成。而程序的运行结构是由快速变化的通信对象网络组成。

7、设计应支持变化。获取最大限度复用的关键在于对新需求和已有需求发生变化时的预见性，要求你的系统要有相应

的变化。下面是一些导致重新设计的一般原因，以及解决这些问题的设计模式：

1)通过显示地指定一个类来创建对象。在创建对象时指定类名将使你受特定实现的约束而不是特定接口的约束。这使未

来的变化更复杂。要避免这种情况，应该间接地创建对象。设计模式：Abstract Factory， Factory Method， 

Prototype。好像现在自己所写的大部分代码都是直接指定一个类创建对象的。

2)对特殊操作的依赖。为了避免把请求代码写死，可以在编译时刻或运行时刻很方便地改变响应请求的方法。

设计模式：Chain of Responsibility, Command

3) 对硬件和软件平台的依赖。设计模式：Abstract Factory， Bridge

4)对对象表示或实现的依赖。 知道对象怎样表示、保存、定义或实现的客户在对象发生变化时可能也需要变化，对客户

隐藏这些信息能阻止连锁变化。

设计模式：Abstract Factory 、Bridge、 Memento、 Proxy

5)算法依赖：有可能发生变化的算法应该被孤立起来

设计模式：Builder、Iterator、Strategy、Template Method、Visitor

6)紧耦合：紧耦合的类很难独立地复用，因为它们是互相依赖的。

设计模式：Abstract Factory、Command、Facade、Mediator、Observer、Chain of Responsibility

7)通过生成子类来扩充功能。通常很难通过定义子类来定制对象。每一个新类都有固定的实现开销。定义子类还需要对

父类有深入的了解

设计模式：Bridge，Chain of Responsibility，Composite，Decorator，Observer，Strategy。

8)不能方便地对类进行修改。有时你不得不改变一个难以修改的类。也许你需要源代码而又没有，或者可能对类的任何

改变会要求修改许多已存在的其他子类。设计模式提供在这些情况下对类进行修改的方法。

设计模式：Adapter，Decorator，Visitor

(引自 《设计模式--可复用面向对象软件的基础》)