最近重读《Java与模式》这本书，为了达到比较好的学习效果，特将学习过程中的学习笔记放在blog中，希望进步大点，嘻嘻。
       1. 概念
           简而言之,人们在自己的环境中不断发现问题和寻找问题的解决方案的时候,发现有一些问题及其解决方案不断变换面孔重复出现,但是这些不同的面孔后面有着共同的性质,这些不同的本质就是模式.
       2. 要素
          1) 名字(Name): 一个模式必须是一个有意义的、简短而准确的名字。一个好的名字可以使对模式的抽象变得容易。有时一个模式同时有多于一个的名字，这时候这些名字就应当作为别名列出;
          2)问题（Problem）：每一个模式必须有一个能够描述它的用意的问题，以便能够说明此模式在给定的环境和力中要达到的目标和结果;
          3)环境和初始环境（Context和Initial Context）：模式的问题和模式的解答出现所需要的前提条件。环境说明模式的适用范围，环境也是模式应用之前的起始位形;
          4)力（Forces）：力给出与模式有关的力和约束，它们能够彼此相互作用，以及它们能实现目标所起的反作用，比如一个模式为所获得的好处付出的代价等。要比较好地描述一个模式，就必须完整地给出所有对模式有影响的力。
          5)解答（Solution）：相当于一个生产产品的指令，它可能包括相片、图表、文字，用于确定模式的结构、所涉及的角色以及角色之间的协作，解答要显示出问题是怎样得到解答的等。解答不仅要给出静态的结构，而且要给出动态的行为;
         6)举例（Examples）：可以使用一个或多个示意性的应用来说明特定的真实环境，以及模式是怎样应用到环境上、改变环境并且给出当模式结束时的末态环境的;
         7)末态环境（Resulting Context）：模式应用到环境之后的状态或位形。末态环境包括模式带来的好的和坏的结果，以及新状态中含有的其他问题和可能设计的其他有关系的模式;
         8)推理（Rationale）：推理解释本模式的步骤、规则，以及此模式作为一个整体是如何以特定的方式解决模式的力的，以及力和模式是如何协同合作的;
         9)其他相关模式（Related Patterns）：这一要素应当描述在现有的系统中这个模式与其他模式的静态和动态的关系;
         10)已知的应用（Known Uses）：在已有系统中模式出现和应用的例子。
         为什么大多数程序员的代码中充斥如此多的if...else判断?
         为什么我们用着面向对象的语言进行着如此多的面向过程编程的重用?
         很多时候我们过多的注重技术表面的东西,而忽视了本应该注重的实质,虽然其中的原因也不全是因为我们自己,学校的教育、企业的急功近利等等都有一部分原因在里面。
         充斥的一大堆框架，struts、hibernate、spring......, 的确为我们减轻了很多工作，但我觉得如我这样的程序员们，也应该花点时间来学习或研究一下算法、设计模式等。努力使自己不断提升。
         当你回想自己所做的技术，发现很多时间都是在ctrl+c、ctrl+v时，你是什么感觉？
         当你发现自己的创造力正在慢慢的减退时，你如何采取行动？
         当理想与现实发生矛盾时，你如何不解决这些矛盾？
         ......
         变与不变，都在于自己。
         我选择了变，你们的选择是什么呢？
         呵呵，就此发一点小牢骚。
         祝所有的如我一样有梦想的程序员们像个男人般去奋斗，哈哈，虽然I am a girl:)