——选自《设计模式沉思录》

习惯1：经常反思
      对编写模式来说，唯一最重要的事情就是反思。Bruce Anderson是最早对我们的工作产生影响的人之一，早在几年前他就提出了这一点。定期反思一下自己做了些什么。想一想自己构建的系统，自己面临的问题，以及自己是如何解决（或无法解决）它们的。

习惯2：坚持使用同一套结构
      把模式写到纸上的第一步就是确定它的结构。模式的平均信息量越大，结构的重要性就越高。一致的结构可以增加模式的统一性，让人们更容易对模式进行比较。结构还有助于人们搜索信息。结构越简单就越单调，如果只是让人随便看看，可能不成问题，但如果还想让它起到比较和引用的作用，就无法接受了。

习惯3：尽早且频繁地涉及具体问题
      由于要涉及具体问题，自然就需要现实世界中的大量例子。例子不应该只是动机部分的专利。从头到尾，都应该用例子和反例来解释一些关键点。即便是我们的模板中最抽象的部分（比如适用性、结构、参与者和协作）也会不时包括一些例子。例如，一些模式的协作部分包含了一些交互图（interaction diagram），用来展示在运行的时候对象之间如何通信。在从抽象的角度讨论模式时，也可以引用这样的例子，即便在讨论抽象概念时也要涉及具体问题。


习惯4：保持模式间的区别和互补性
      一定要确保各个模式是正交的，而且它们可以协同使用。不断地扪心自问：“模式X和模式Y之间的区别是什么？”如果两个模式解决的问题是相同的或具有相似性，那么也许能把它们合并到一起。如果两个模式使用了相似的类层次结构，那么不必担心。面向对象编程提供的机制本来就不多，所以它们的用法也相对有限。同样的类层次结构经常会产生截然不同的对象结构，它们解决的问题也多种多样。模式之间的区别应该由它们的意图来决定，而不是由实现模式的类层次结构来决定。

习惯5：有效地呈现
      这里说的“呈现”有两个意思：排版和写作风格。页面布局的技术、版面、图形以及打印机的质量直接影响到排版的好坏。尽可能使用最好的软件工具（字处理程序、绘图编辑器等）。多使用插图来解释关键点。你也许认为不需要任何插图，但很可能你还是会用到。至少它们可以避免单调乏味，而最好的情况下它们可以将那些语言无法解释清楚的问题解释清楚。并不是所有的插图都必须是正式的类图和对象图。在很多情况下，非正式的插图甚至是草图也能够传达同样多的信息，甚至更多的信息。如果自己不擅长画图，那么可以请别人代劳。

      与好的排版相比，好的写作风格就更加重要了。以清晰直白的方式写作。最好是使用贴近实际的风格，避免枯燥无味的学究风格。通俗的语气比较容易被人理解和接受， 从而让人更快地接纳新内容。清晰性和易读性对大多数写作来说都非常重要，对模式写作来说尤其重要。模式的概念还比较新，如果谈论的内容又比较复杂，那么有些人将完全无法领会其中的要点。要想方设法让模式变得更易理解。


习惯6：不懈地重复
      你需要一遍又一遍地编写和重写你的模式，对此要做好心理准备。不要追求必须等前一个模式到达完美状态后才开始编写下一个模式。记住，模式不是孤立的，它们之间会相互影响。对一个模式所做的显著修改很可能会影响到其他模式。就像任何一个循环往复的过程一样，在某一时刻你的模式会趋于稳定，这时你应该把自己努力的成果汇集起来，供他人阅读、理解并发表评论了，但它并不代表模式开发的终点。

习惯7：收集并吸取反馈
      鼓励你的同事在讨论设计时引用你的模式，并在需要的时候参与到此类讨论中。寻求机会，将你的模式运用到日常工作中去。尽可能广地传播你的模式，甚至可以将它们提交给PLoP之类的会议或C++ Report、Smalltalk Report和Journal of Object-Oriented Programming之类的书刊。这样的曝光可以获得大量良好的反馈。