学习设计模式的层次

基本入门级

要求能够正确理解和掌握每个设计模式的基本知识，能够识别在什么场景下、出现了什么样的问题、采用何种方案来解决它，并能够在实际的程序设计和开发中套用相应的设计模式。

基本掌握级

除入门级需求，还要求能够结合实际应用场景，对设计模式进行变形使用。

事实上，在实际开发中，经常会碰到与标准模式的应用场景有不一样的情况，此时要合理地使用设计模式，就需要对其做适当地变形，而不是僵硬地套用。当然，变形使用的前提是要准确深入理解和把握设计模式的本质，万变不离其宗，只有把握本质，才能确保正确变形而不是误用。

深入理解和掌握级

从思想和方法上吸收设计模式的精髓，并融入到自己的思路中，在进行软件分析和设计的时候，能随意地、自然而然地应用，就如同自己思维的一部分。在复杂的应用中，当需要解决某个问题的时候，很可能不是单一地应用某一个设计模式，而是综合应用很多设计模式。例如，结合某个具体的情况，可能需要把模式A简化，然后结合模式B的一部分，再组合应用变形的模式C，如此来解决问题。

简单地说，基本入门级就是套用使用，相当于能够照葫芦画瓢，较为机械；基本掌握级就是能变形使用，比基本入门级灵活，可适当变形使用；深入理解和掌握级才算是真正将设计模式吸收，是从思想和方法的层面上去理解和掌握设计模式，无招胜有招。

简单是设计的简单

简单不是功能的简单，而是设计的简单。简单的设计意味着缺少灵活性，代码刚硬，只在这个项目中有用，拿到其它项目中就无用，这是"一次性代码"。

要使代码可被反复使用，就需要用设计模式对代码进行设计。但是不能陷入模式的陷阱，为了使用设计模式而去套模式，这样就会陷入形式主义，在使用模式的时候，一定要注意模式的意图，而不要过多地关注模式的实现细节，因为这些实现细节再特定的情况下，可能会发生改变，不能顽固地认为设计模式一书中的类图或实现代码就代表了模式本身。

防止紧耦合、坏味道。

软件设计固有的复杂性诱发了设计模式的诞生

问题领域的复杂性:客户需求本身就复杂，客户和开发人员互相不理解。

管理开发过程的困难：开发是由人完成的，人的组织、潜能存在巨大复杂性。

软件可能的灵活性:软件为开发人员提供了极大的灵活性，而开发人员容易滥用这种灵活性。

表征离散系统行为的困难:软件系统本质上是一个离散系统，其复杂度远大于连续系统。一个简单的外部事件可能破坏整个系统。

如何解决复杂性

分解：分而治之，将大问题分解为小问题，将复杂问题分解为多个简单问题

抽象：处理复杂性有一个通用的技术，即抽象。由于不能掌握全部的复杂对象，我们会忽略其非本质细节，而去处理泛化和理想化了的对象模型。

重新认识面向对象

从宏观层面看，面向对象的构建方式更能适应软件的变化，能将变化所带来的影响减为最小。

从微观层面看，面向对象的方式更强调各个类的责任，新增员工类型不会影响原来员工类型的实现代码--这更符合真实的世界，也更能控制变化所影响的范围。