一 Think in pattern

Thinking

in

Patterns

Problem-Solving Techniques using Java

Bruce Eckel

President, MindView, Inc.

Omencathay 翻译

2007-9-9

前言

本书中的材料是伴随一个我进行几年的研讨会的产物，大多数是与Bill Venners一起共事。我和Bill对这个研讨会进行了很多次迭代并且我们改变了它很多次在这些年间，当我们都了解了更多的模式并且研讨会上所给出的。

在这个过程中，我们两人都有足够的信息举行我们自己的研讨会，我们都有一种强烈的动机汇总如此多有趣的研讨会材料到一起。我们在美国的很多地方举行了研讨会，包括布拉格（在那我们尝试每个春天都进行一个迷你讨论会）。我们同样也有在线的研讨会议。

十分感激这些年中参加研讨会的人们，他们帮助我整理出这些思想并且进行升华。我希望能够通过这本书和研讨会继续形成和开发这种思想在未来的几年中。

这本书也不会在这里止步。深思熟虑后，我意识到我想思考什么是Python，最初是翻译这本书而非一个Python的介绍（早已经有很多介绍对这门华丽的语言）。我发现这个前景是更令人激动的相比苦足于另一门语言教程的思想来说。

简介

这是一本关于设计的书，我已经在这上面花费了很多年的时间，基本上，每次我尝试开始阅读《设计模式》(Gamma, Helm, Johnson & Vlissides, Addison-Wesley, 1995)，都会参考GOF。

在第一版的《Think in C++》有一章是关于设计模式的，在第二版的《Think in C++》第二卷已作了改进，你同样也能在第一版的《Think in java》发现有一章是关于设计模式的，我从《Think in java》第二版中去掉了这一章，因为我发现这本书变得太大了，并且也是因为我决定写本书。

这不是一本介绍手册。我假定阅读本书之前通读了《Think in java》或者同等的书籍。

此外，我假定你对java语法有很深刻的领会。你应当很好的理解对象，并且它们到底是什么，包括多态。再一次，这些主题贯穿了《Think in java》一书。

另一方面，遍历本书你将学会很多关于面向对象编程，通过查看对象在很多不同情况下的应用。如果你还对面向对象的知识还处于起步阶段，在理解本书的设计过程中你会更加完善。

千年虫综合症（The Y2K syndrome）

在一本的副标题有“解决问题技巧”的书中，程序设计中有一个最大的缺陷是值得提及的：提早优化。每次我提到这个概念，事实上很多人都同意。并且每个人都保留他们自己想法的一个特例，“除了我碰巧知道的这事以外是个特殊的问题”。

我称这些为千年虫综合症的原因不得不用专门的知识来处理。对大多数人计算机是神秘的，因此当有人宣称那些愚蠢的程序员忘记了放置足够的数位存储日期经过1999年，然后突然的每个人都变成了计算机专家---“那些事毕竟不是如此困难，如果我能看见一个如此显而易见的问题的话。”例如，我最初是学计算机工程的，并且我始于编写嵌入式系统。结果是，我知道许多嵌入式系统对日期和时间毫无概念，并且甚至数据经常不被用于任何重要的计算。可是，我被毫不确定的告知，所有的嵌入式系统将要爆发一场灾难在2000年1月1日。据我所知，在那个特别的日子唯一失忆的时那预言灾难的人们---似乎它们从来没有说过那些话。

关键在于这是非常容易落入思维定势的，考虑你碰巧部分的或完整的理解特定的算法或编码段很自然的变成你系统的瓶颈，简单的因为你能够想象那个代码段的运行，并且据此认为它一定比所有其他的你不知道的编码段更无效率。除非你确实运行了一个测试，典型的用一个模具，你不可能知道他究竟是怎样的。即使你是正确的，那样一段编码非常低效，记住程序中少于10%的编码占用了90%的时间，因此除非你所思量的代码段恰好在这10%内，否则它并不是重要的。

97%的情况下，我们不应当关心小的效能问题：“提早优化是邪恶的根源”—Donald Knuth

上下文和组合（Context and composition）

你将看到在设计模式的作品中被反复使用的一个术语是：context。事实上，一个设计模式的一个公认的定义就是“在一个上下文的语义中解决问题的方案。”GOF模式经常有一个“上下文对象”，客户端程序员与之相交互。在某点上，它提醒了我这种对象在许多设计模式上处于支配地位，因此我开始探求他们究竟是什么。

上下文对象经常充当一个小的界面来隐藏模式其余部分的复杂，此外他经常是控制器管理模式的操作。最初，对我来说它看起来似乎不重要的在模式的实现，使用和理解。然而，我深刻地记得GOF里面的一句话：“宁组合，勿继承。”上下文对象允许你以一种组合的方式来使用模式，这也许是它的主要价值所在。

关于已检测异常（A word about checked exceptions）

1)异常的最大价值在于统一的错误报告：通过一个标准的机制报告错误，而非C中可忽略方式的大杂烩方式（C++中，仅仅混合添加异常，不是唯一手段）。JAVA优于C++的最大好处是只有一种方式报告错误的异常。

2)上一段中提到的“可忽略的”是另一个议题。原理是如果编译器强制程序员或者是调度异常或者是传递它到一个异常说明书中，那么程序员的注意力将总是被带到错误的可能性，并且他们将恰当处理他们。我认为问题在于我们如同语言设计者主观做的一个未经测试的假设。我的理论就是当某人尝试做某事的时候，并且你正持续不断的用恼人的事刺激他们，他们会使用最快速的可用策略让这些恼人的事远离，这样他们能够做好他们的事，也许，想象他们过后返回卸下那个策略的情况会怎样。我发现我曾经这样做过在第一版的《Think in java》中：

...

} catch (SomeKindOfException e) {}

那时或多或少的会忘记上面的代码，直到重写时才记起。有多少人认为这是个好的例子并且效仿？Martin Fowler开始看到同样的代码，并且意识到人们漠视异常，异常就那样消失了。高高在上的已检测异常背离他所期望的效果，当你试验的时候他们就会发生（现在，我认为已检测异常是一个试验，基于某人的想法是一个好的主意，直到最近我一直确认那是一个好主意）

当我开始使用Python时，所有的异常都出现了，没有一个被屏蔽。如果你想捕获一个异常，你能够，你不会被强制去写大量的代码仅仅用来传递异常。他们会出现在你想捕获的地方，或者你忘记它们在哪，他们也不会消失，这是所有可能例子中最坏的一种情况。现在，我确认已检测异常鼓励人们让他们消失，插入他们会是代码可读性很差。

最终，我认为我们必须了解异常的实验本性，并且在假设Java中每种异常都是好的前提下仔细的审视它们。我相信拥有处理错误的单一机制是优秀的，并且应用一个分离的渠道（异常处理机制）传递异常也是好的。但是我依然记得C++中一个早期的用于异常处理的参数，它允许程序员分离代码片断，在那里你刚好想要处理错误，使任务得到处理，看起来似乎已检测异常并没有做什么；事实上，他们想要塞入一些东西到你“正常的工作代码”，这不能不说是一个倒退。我使用python异常的经验支持这点，除非我改变这个观点，我才会想在我的java代码里添加许多RuntimeExceptions。

omencathay 译

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25966/viewspace-53309/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25966/viewspace-53309/