软件开发的一个不变真理
变化！！！change！！！
变化！！！change！！！
变化！！！change！！！
定义
模式是在某情景（context）下，针对某问题的某种解决方案。
- 情景就是应用某个模式的情况。这应该是会不断出现的情况。
- 例如：你拥有一个对象的集合。
- 问题就是你想在某情境下达到的目标，但也可以是某情境下的约束。
- 你需要注意走访每个对象，而且不需理会该集合的实现。
- 解决方案就是你所追求的：一个通用的设计，用来解决约束、达到目标。
- 将迭代封装进分离的类中。
为什么使用设计模式
- 设计模式让你和其他开发人员之间有共享的词汇，一旦懂得这些词汇，和其他开发人员之间的沟通就很容易，也会促使那些不懂的程序员想开始学习设计模式。
设计模式也可以把你的思考架构的层次提高到模式层面，而不是仅停留在琐碎的对象上。
共享模式词汇的威力
共享的模式词汇“威力强大”。当你使用模式名称和其他开发人员或者开发团队沟通时，你们之间交流的不只是模式名称，而是一整套模式背后所象征的质量、特性、约束。
- “我们使用策略模式实现鸭子的各种行为。”这句话也就是告诉我们，鸭子的行为被封装进入一组类中，可以被轻易的扩充与改变。如果需要，甚至在运行时也可以改变行为。
- 模式能够让你用更少的词汇做更充分的沟通。当你用模式描述的时候，其他开发人员很容易地知道你对设计模式的想法。
- 将说话的方式保持在模式层次，可以让你待在“设计圈子”久一点。使用模式谈论软件系统，可以让你保持在设计层次，不会被压低到对象与类这种琐碎的事情上面。
- 想想看，有多少次的设计会议中，你们一不小心就进入了琐碎的实现细节的讨论上。
- 共享词汇可帮你的团队快速充电。对于设计模式有深入了解的团队，彼此之间对于设计的看法不容易产生误解。
共享词汇能帮助初级开发人员迅速成长。初级开发人员向有经验的开发人员看齐。当高级开发人员使用设计模式，初级开发人员也会跟着学。把你的组织建立成一个模式使用者的社区。
如何使用设计模式
我们全都使用别人设计好的库与框架。但是库与框架无法帮助我们将应用组织成容易了解、容易维护、具有弹性的架构，所以需要设计模式。设计模式不会直接进入你的代码中，二十先进入你的“大脑”中。一旦你现在脑海中装入了许多关于设计模式的知识，就能够在新设计中采用他们。
如果设计模式这么棒，为何没有人建立相关的库呢？那样我们就不必自己动手了。
- 设计模式比库的等级更高。设计模式告诉我们如何组织类和对象以解决某种问题。而且采纳这些设计并使它们适合我们特定的应用，是我们责无旁贷的事。
- 库和框架不也是设计模式么？
- 库和框架提供了我们某些特定的实现，让我们的代码可以轻易的引用，但是这并不算是设计模式。有些时候，库和框架本身会用到设计模式，这样很好，因为你一旦了解了设计模式，会更荣誉了解这些API是围绕着设计模式构造的。
那么，没有所谓的设计模式库？
认识她 - 知道有这个模式
- 了解她 - 知道设计模式的优缺点，能解决什么样的问题
- 追到手 - 理解设计模式，能够在代码中运用设计模式
-
写在最后
记住，知道抽象、继承、多态这些概念，并不会马上让你变成好的面向对象设计者。设计大师关心的是建立弹性的设计，可以维护，可以应付变化。
- 如果找不到设计模式，怎么办？
- 有一些面向对象原则，适用于所有的模式。当你无法找到适当的模式解决问题时，采用这些原则可以帮助你。建立可维护的OO系统，要诀就在于随时想到系统以后可能需要的变化以及应付变化的原则。
- 记住，设计是一门艺术，总是有许多可取舍的地方。但是如果你能采用这些经过深思熟虑，且经受过时间考验的设计模式，你就领先别人了。
要点
- 知道OO基础，并不足以让你设计出良好的OO系统。
- 良好的OO设计必须具备可复用、可扩展、可维护三个特性。
- 模式可以让我们建造出具有良好OO设计质量的系统。
- 模式被认为是历经验证的OO设计经验。
- 模式不是代码，而是针对设计问题的通用解决方案。你可以把他们应用到特定的应用中。
- 模式不是被发明，而是被发现。
- 大多数的模式和原则，都着眼于软件变化的主题。
- 大多数的模式都允许系统局部改变独立于其他部分。
- 我们常把系统中会变化的部分抽出来封装。
- 模式让开发人员之间有共享的语言，能够最大化沟通的价值。
若有收获，就点个赞吧
0 人点赞
