OO设计中对象的创建和使用.doc

对象设计中创建VS使用 作者：Scott L.Bian 译者：李澍 目录 背景 引用Martin Fowler的观点 我的新视角 对象使用的视角 分离对象的创建 实际编程中的分离观点 总结 背景 这篇文章是我在Net Objectives工作时写的，我在那里的工作是指导人们编写有效的面向对象程序。本文将介绍一些实用但不同以往的观点，用来解决每天出现的设计问题。本文不关注对象做什么，而是对象的使用和对象的实例化。基于这些观点，可以大规模地简化和改进代码，以满足将来维护的需要。 引用Martin Fowler的观点 在《UML精粹》第三版中，Martin Fowler提出了对象设计的三个层面：概念层、规约层（Specification）、实现层 概念层，概念层中的对象是承担一定职责的实体，通常用抽象类和接口（Interface）来描述，这些实体之间以各种方式相互联系来实现应用系统的目标。 如果我是一个对象，在概念层我关心的是“我的职责是什么”。 规约层，规约层中的对象通过它的公共方法来实现它的职责，每个公共的方法都是对象按照指定的方式提供的服务。 如果我是一个对象，在规约层我关心是“别人如何使用我” 实现层，实现层是对象的代码，对象通过代码来实现它的职责。 如果我是一个对象，在实现层我关心的是“我如何完成我的职责” 要清楚的认识到，先关注什么特性，什么以后再关注，这是一个很有用的做事方法（所有工作都适用）。要成功认知的实践一项复杂活动，这些特性往往是问题的关键。 在软件开发的活动中，内聚性就是这种特性。对于系统内的一个实体，内聚性的概念是指这个实体内部的紧密程度。当我们谈到“强内聚”这个术语，也就是指某些的打包在一起的东西属于同一个功能（对方法而言）、同一个职责（对类而言）或是同一个领域（对包而言）。相反，如果把很多不相关的东西混在一个包里，我们称这为弱内聚。例如：一个系统只有一个类，这个类负责所有的事，还含有一个上帝方法，能做所有的事 藕合，是另一个关键特性。这个概念是指系统的实体之间依赖程度。依赖性越强，关系就会越错综复杂，系统也就越难以维护。 对于系统中一个实体，只立足于一个概念层次来工作，有很有益处的。同样的，把自己的思维过程划分成三部分也是有利的： 首先，这样有助于减弱藕合。如果对象之间的关系保持在抽象层面上，后期实现的子类之间的藕合会更弱。这些意见是设计模式的作者“Gang of Four”他们提出的。他们认为设计者应该“面向接口作设计”。 其次，能使系统内聚性更好结构更清楚，因为我们能围绕对象的职责来编写实现细节，而不是其它的方式。这样，一个对象被明确的定义职责范围，而并不是包含一些无关的方法和状态（这对眼前的问题豪无帮助）。 最后，其它开发者能因此有一个清楚的认识过程，因为如果对一个问题，让一个人同时从多个层面去理解它，那么他将很容易泄气。 我的新观点 下面才是正题，我将推荐一些观点，这是些类似的特性，它能帮助我们实现灵活性和健壮性，而这正是我们一直在寻找的面向对象方法。我把我的这些观点概括为：对象创建VS对象使用。 我们看看下面这段代码： public class SignalProcessor { private ByteFilter myFilter; public SignalProcessor() { myFilter = new HiPassFilter(); } public byte[] process(byte[] signal) { // Do preparatory steps myFilter.filter(signal); // Do other steps return signal; } } 这是一个SignalProcessor的例子，它使用ByteFilter的一个实现（HiPassFilter）来完成自己的一部分工作。基本上这是不错的作法，内聚性是比较好的，每个类是一个整体，通过和其它类协作来完成自己的任务。并且，对于ByteFiler可以提供多种实现，而不需要改变SignalProcessor的设计。这是一个“可拔插”的设计，并且很容易扩展。 概念上，SignalProcess是负责处理字节数组的信号。规约方面，SignalProcessor表现为一个返回字节数组的process()方法。 而SignalProcessor的实现的方面。我们看到，SignalProcessor调用ByteFilter的实例，在我们经过这里的时候，我们只需考虑它的规约（filter()方法）,而不需考虑它的实现。这样很好，干净清楚。 但是，问题在于，SignalProcessor和ByteFilter之间的调用混合了两种不同的概念（创建的概