我们个人认为写java程序的一般境界莫过于此了 ^_^ (转贴)

从面向对象到模式再到真正的面向对象


Alan Shalloway 著 透明 译

（译序：
本文摘自Design Patterns Explained: A New Perspective on Object-Oriented Design一书的前言部分。通过本文，读者可以大概了解学习设计模式的过程和效果。同时，作者谦虚谨慎的态度也是非常值得我们中国软件开发者学习的。
译者保留本文一切权利。如果需要将本文用于非营利性目的，请E-mail通知我：gigix@263.net）

这本书的很多地方都复述了我自己学习设计模式的经验。在学习设计模式之前，我认为自己理所当然是面向对象分析和设计的专家。我曾经为各种行业的客户做过一些还算给人深刻印象的设计和实现。我会使用C++并且已经开始学习JAVA。我的代码中的对象格式优美封装紧密。我可以在继承体系中设计优秀的数据抽象。我想我已经懂得面向对象了。

现在回头看看，我发现那时其实我还根本不知道面向对象设计的全部能力，尽管我一直按照专家建议的方式来做。直到我开始学习设计模式，我的面向对象设计能力才得到了扩展和深化。学习设计模式使我成为了一个更好的设计者，甚至是我还没有直接使用那些模式的时候。

我从1996年开始学习设计模式。当时我正在西北部一家大型航天公司担任C++/面向对象设计顾问。有几个人劝说我领导一个设计模式学习组。正是在那里我遇到了本书的另一个作者Jim Scott。在那个学习组中发生了几件有趣的事情。首先，我开始对设计模式着迷。我可以把自己的设计和其他更有经验的人的设计相比较，我爱上了这种感觉。另一方面，我发现我并没有完全做到"对接口做设计"，也没有随时注意"一个对象是否可以在不知道另外对象的类型的情况下使用另外对象"。同时我注意到，那些面向对象的初学者--通常他们被认为过早开始学习设计模式--从这个学习组得到的收益与那些面向对象的专家不相上下。设计模式向学习者展现出优秀的面向对象设计实例并阐述基本的面向对象设计原则，而这些使学习者的设计更快地成熟起来。在整个学习进程结束之后，我确信：设计模式，这是面向对象设计被发明之后软件设计中最好的东西。

但是，看看那个时候我自己的工作，我发现我根本还没有在自己写的代码中结合任何一个设计模式。

当时我只是认为自己还没有学到足够的设计模式，还需要学习更多。那时候，我只知道六个设计模式。然后我可以说是得到了顿悟。我在一个项目中担任面向对象设计顾问，并需要为这个项目创建一个高层设计。这个项目的领导人极其聪明，但在面向对象设计领域，他可以说是一个新手。

这个问题本身并不困难，但需要非常注意确保代码容易维护。按照惯例，在看过问题两分钟之后，我便有了一个设计--采用了我常用的数据抽象的途径。很不幸的是，很显然这不会是一个好的设计。简单的数据抽象已经让我尝到过失败的滋味。我必须找到一些更好的设计思路。

两个小时过去了。在使用了我所知道的所有设计技术之后，情况仍然没有好转。我的设计基本上都还是和从前一样。而最让我感觉受挫的是，我知道一定有一个更好的设计，但我就是找不到它。更具讽刺意义的是，我甚至还知道四个设计模式就"生活"在我的问题中，但我看不出应该如何使用它们。在这里，我，一个被认为是面向对象设计专家的人，被一个简单的问题困住了！

我实在觉得很受挫，于是我停了下来，开始绕墙行走以清醒头脑，并告诉自己：至少10分钟里我不再想这个问题。呵呵，30秒之后，我又开始想它了！但我获得了一种领悟并完全改变了我对设计模式的看法：设计模式无法作为独立的条款使用；我应该把设计模式放在一起使用。

模式是应该被结合在一起来共同解决一个问题的。

以前我曾经听到过这句话，但那时我并没有真正理解它。因为软件开发中的模式往往被介绍为"设计模式"，所以我总是在"模式最主要的贡献是在设计阶段"的假设下努力。我的想法是：在设计世界里，模式就好象是类之间优美的联系。然后，我阅读了Christopher Alexander那本令人惊讶的书--The Timeless Way of Building。我学到了：模式存在在所有的阶段--分析、设计以及实现--之中。Alexander在书中讨论了如何使用模式来帮助理解（乃至描述）问题领域，而不是仅仅在理解了问题领域后使用模式来创建一个设计。

我的错误是：我尝试先创建问题领域中的类，然后将这些类缝合起来形成最终的系统--Alexander把这样的过程称为"一个坏主意"。我从来没有问过自己：我是否拥有正确的类？仅仅因为这些类看起来如此正确、如此明显。我拥有的，是在我开始分析时立刻进入了我的脑海的类，是我们的老师告诉我们应该在系统的描述中寻找的"名词"。但是我的错误就是我仅仅尝试把它们简单的放在一起。

当我回过头，开始使用设计模式和Alexander的方式来指导自己创建我的类时，仅仅几分钟之后，一个优秀得多的解决方案在我的脑海中显露出来。这是一个很好的设计，于是我们把它应用在产品之中。我很兴奋--为我设计了一个好的解决方案，更为设计模式的威力。从此，我开始在自己的开发工作和教学中结合设计模式。

我开始发现，那些刚开始学习面向对象设计的程序员也可以学习设计模式。并且他们可以在这个学习过程中为自己的面向对象设计能力打好基础。这对于我自己是真的，对于我所教的那些学生也是真的。
想象一下我的惊讶！我读过的设计模式书籍和与我交谈过的设计模式专家都曾经告诉我：在开始学习设计模式之前，你真的需要认真进行面向对象设计的基础训练。然而，我用我自己的眼睛看见，同时学习面向对象设计和设计模式的那些学生，他们掌握面向对象设计的进度比那些只学习面向对象设计的学生更快。甚至他们掌握设计模式的进度看上去几乎和那些有经验的面向对象实践者一样快。

我开始把设计模式用做我的教学基础。我开始把我的课程叫做"面向模式设计：从分析到实现的设计模式"。

我希望我的学生能理解这些模式，并且我发现使用一个探索的过程是帮助他们理解的最好办法。举个例子，我发现如果要向学生们讲解Bridge模式，我最好能向他们展示一个实际问题，然后让他们尝试为这个问题设计一个解决方案。我会给他们一些指导性的原则和策略--我发现大多数设计模式都指出了这些。经过这个探索过程，学生们最后找到了解决方案--被称为Bridge模式--并牢牢记住了它。

无论如何，我还发现这些指导性的原则和策略可以用来"派生"出这些设计模式中的几个。"派生出一个设计模式"，我说这句话的意思是：如果我看到一个问题并且知道可以用一个设计模式来解决这个问题，我就可以通过这些指导性的原则和策略来得到该模式所表达的解决方案。我向我的学生们明确指出，我们不会真的通过这种方法得到设计模式。我只是阐明一种可能的思考过程。模式的发现者通过这样的过程得到了最初的解决方案，并最终把解决方案归类成设计模式。

一段小小的离题

在我现在看来，这些指导原则及策略都非常清楚了。当然，它们在"四人帮"的设计模式书中都有描述。但是，由于我自己对面向对象范式的理解有限，我花了很多时间来理解这些原则和策略。直到我在自己的思想中结合了四人帮及Alexander的工作、Jim Coplien在通用性和可变性上的工作、Martin Fowler在方法论和分析模式上的工作之后，这些原则对我才算足够清楚，我才能和他人谈起这些原则。这帮助我决定开始为他人解释一些东西的生活，这样我不会过分轻易的假想自己的能力--当仅仅为自己工作时，我很容易产生这样的假想。

我的能力可以帮助我更好的解释这几个很有威力的原则和策略。并且当我开始解释更多四人帮的模式时，它们更加有用了。实际上，在我设计模式课程中，我用这些原则和策略来解释12到14个模式。

我还发现，我开始在自己的设计中使用这些原则，不管是否使用设计模式。这并没有让我感到惊讶。如果使用这些原则和策略最终让我的设计中出现了一个设计模式，这就是说它们给了我得出优秀设计的方法（因为设计模式都是已经得到承认的优秀设计）。如果使用了这些技术，难道我还会因为不知道某个模式--不管它是否出现--的名字而得到不好的设计吗？

这些领悟帮助我更好的进行我的训练过程（以及我现在的写作过程）。我已经把我的教学进行了好几个阶段。我正在向学生们教授面向对象分析和设计的基础。我在课程中教授设计模式、使用它们来阐述优秀的面向对象分析和设计的例子。另外，通过使用设计模式来教授面向对象概念，我让我的学生们更好的理解了面向对象的原则。而且通过学习指导性原则和策略，我的学生们现在可以创建出质量与模式相媲美的设计。

我在这里讲这个故事，因为本书所讲的模式几乎与我的课程所讲的一样。实际上，从第三章开始，这本书基本上就是我的两天课程--面向模式的设计：从分析到实现的模式--中的第一天。

阅读本书，你可以学到这些模式。但更重要的是，你可以学到：为什么它们可以起作用？它们怎样在一起工作？以及它们所依赖的原则和策略。这对你积累自己的经验将很有帮助。当我在本书中展现出一个问题时，如果你能联想到一个你曾经历过的类似的问题，这将对你很有帮助。本书并不讲述新的知识或新的模式，而是给你一个看待面向对象软件开发的新的视角。我希望在你的学习过程中，你自己的经验与设计模式的原则结合之后能形成一个强有力的联盟。

Alan Shalloway
2000年11月

补充：
我们不能一直的只顾着写程序，需要学习设计模式，况且java是纯面向对象的语言

个人认为如果一个程序员不懂设计模式的程序员和不懂数据结构的程序员一样，都是一个不合格的程序员！！！

原文转自：http://www.ltesting.net