设计模式杂谈
对编写模式来说，唯一最重要的事情就是反思。Bruce Anderson是最早对我们的工作产生影响的人之一，早在几年前他就提出了这一点。定期反思一下自己做了些什么。想一想自己构建的系统，自己面临的问题，以及自己是如何解决（或无法解决）它们的。
习惯2：坚持使用同一套结构
把模式写到纸上的第一步就是确定它的结构。模式的平均信息量越大，结构的重要性就越高。一致的结构可以增加模式的统一性，让人们更容易对模式进行比较。结构还有助于人们搜索信息。结构越简单就越单调，如果只是让人随便看看，可能不成问题，但如果还想让它起到比较和引用的作用，就无法接受了。
习惯3：尽早且频繁地涉及具体问题
由于要涉及具体问题，自然就需要现实世界中的大量例子。例子不应该只是动机部分的专利。从头到尾，都应该用例子和反例来解释一些关键点。即便是我们的模板中最抽象的部分（比如适用性、结构、参与者和协作）也会不时包括一些例子。例如，一些模式的协作部分包含了一些交互图（interaction diagram），用来展示在运行的时候对象之间如何通信。在从抽象的角度讨论模式时，也可以引用这样的例子，即便在讨论抽象概念时也要涉及具体问题。
习惯4：保持模式间的区别和互补性
一定要确保各个模式是正交的，而且它们可以协同使用。不断地扪心自问：“模式X和模式Y之间的区别是什么？”如果两个模式解决的问题是相同的或具有相似性，那么也许能把它们合并到一起。如果两个模式使用了相似的类层次结构，那么不必担心。面向对象编程提供的机制本来就不多，所以它们的用法也相对有限。同样的类层次结构经常会产生截然不同的对象结构，它们解决的问题也多种多样。模式之间的区别应该由它们的意图来决定，而不是由实现模式的类层次结构来决定。
习惯5：有效地呈现
这里说的“呈现”有两个意思：排版和写作风格。页面布局的技术、版面、图形以及打印机的质量直接影响到排版的好坏。尽可能使用最好的软件工具（字处理程序、绘图编辑器等）。多使用插图来解释关键点。你也许认为不需要任何插图，但很可能你还是会用到。至少它们可以避免单调乏味，而最好的情况下它们可以将那些语言无法解释清楚的问题解释清楚。并不是所有的插图都必须是正式的类图和对象图。在很多情况下，非正式的插图甚至是草图也能够传达同样多的信息，甚至更多的信息。如果自己不擅长画图，那么可以请别人代劳。
与好的排版相比，好的写作风格就更加重要了。以清晰直白的方式写作。最好是使用贴近实际的风格，避免枯燥无味的学究风格。通俗的语气比较容易被人理解和接受， 从而让人更快地接纳新内容。清晰性和易读性对大多数写作来说都非常重要，对模式写作来说尤其重要。模式的概念还比较新，如果谈论的内容又比较复杂，那么有些人将完全无法领会其中的要点。要想方设法让模式变得更易理解。
习惯6：不懈地重复
你需要一遍又一遍地编写和重写你的模式，对此要做好心理准备。不要追求必须等前一个模式到达完美状态后才开始编写下一个模式。记住，模式不是孤立的，它们之间会相互影响。对一个模式所做的显著修改很可能会影响到其他模式。就像任何一个循环往复的过程一样，在某一时刻你的模式会趋于稳定，这时你应该把自己努力的成果汇集起来，供他人阅读、理解并发表评论了，但它并不代表模式开发的终点。
习惯7：收集并吸取反馈
鼓励你的同事在讨论设计时引用你的模式，并在需要的时候参与到此类讨论中。寻求机会，将你的模式运用到日常工作中去。尽可能广地传播你的模式，甚至可以将它们提交给PLoP之类的会议或C++ Report、Smalltalk Report和Journal of Object-Oriented Programming之类的书刊。这样的曝光可以获得大量良好的反馈。
了这个帖子，有感写点废话
http://www.javaeye.com/topic/243309
现在随便哪个面试不考点设计模式什么的，似乎就不叫面试，我倒想问问，面试官们你们自己不算那些死记硬背的，能记住多少模式的思想，又有多少是你们每天写的程序会用到的
我承认
1. 设计模式确实是前人总结的一些经验和良好的设计范式，是很有价值的
2. 把握良好的设计模式能够理清程序的骨架，使程序变得更清晰
但是我很想说的是
1.设计模式是最通用的一些程序设计方法和范式，不同的领域有自己的一些模式可以遵循，未必非得是那20几种里的某一个
2.书中列举的那些模式是死的，只是特定问题的一些设计思路，未必就非得那样，生搬硬套是很傻的行为
3.设计模式这东西没写过一定得代码量，看了书上写的那些也未必理解，代码量积累到一定程序（当然不是每天重复的体力劳动，需要勤思考），自然会对特定领域，或特定问题有自己的一套解决方法或者设计范式，很可能早就有了一套自己的组件库，所以也不需要去看书上那些死的东西，该会的你都会了，其他的你也用不到
所以基本上 面试时考个什么叫包装，什么叫工厂，抽象方法的实在是没什么意义，都成了背书了
举个最简单的例子，设计模式书上讲包装设计模式废了那么多笔墨，又是抽象类，又是接口的，累不累呀，其实可能天天都用的东西，不搞复杂点就不叫高深，这样难道不叫包装吗？
Java 代码
1. public interface Display{
2. String display();
3. }
4.
5. public class DisplayWrapper implements Display{
6. private Display display;
7. public DisplayWrapper(Display display){
8. this.display=display;
9. }
10. public String display(){
11. String s=display.display();
12. //wrapper自己的处理
13. }
14. }
public interface Display{
String display();
}
public class DisplayWrapper implements Display{
private Display display;
public DisplayWrapper(Display display){
this.display=display;
}
public String display(){
String s=display.display();
//wrapper自己的处理
}
}
很多程序员几乎认为，封装得不花个半天功夫根本找不到实现类在哪 这就是面向对象的美，就是面向对象的最高境界，简单的事情往往搞的N复杂
我就是想说 简单的就是最好的，简单的往往也是强大的
粗浅见解，有拍砖的欢迎
