你怎么知道什么时候使用devise模式？
任何人都可以阅读GoF的书来了解devise模式是什么以及如何使用它们，但是当devise模式解决问题时，要弄清楚什么是devise模式？ 模式的知识是否推动devise，还是有办法弄清楚如何使用模式来改变devise？
换句话说，模式有没有模式？
devise模式应该提供一个可以解决问题的结构。 当解决一个真正的问题时，你必须考虑解决这个问题的许多微小的变化，看是否有任何符合devise模式。 特别是，你可能需要概括你的问题或其解决scheme，以使devise模式合适。
答案是，这是一门艺术。 了解devise模式无疑是重要的一步。 一种习惯这种事情的方式是研究devise模式的应用 ，而不仅仅是模式。 看到一个模式的许多不同的应用程序可以帮助你随着时间的推移，更好地将任务映射到模式。
我强烈build议阅读O'Reilly的Head First Design Patterns 。 这解释了如何在现实世界中使用这些模式。
我还要补充一点，不要过多地考虑devise。 更多的是，寻找一种模式可能有助于解决的“代码气味”。
把问题翻过来：你应该做的模式是“什么模式适合我的问题”。 考虑一个非常简单的模式，在数组中find一个元素。 在C中，这是类似的
TYPE_t ary[SIZE] = // ... gets initialized somehow size_t ix ; // Your index variable for(ix=0; ix < SIZE; ix++){ if (ary[ix] == item) { return ix ; } } 你不看代码，并想“我在哪里可以使用”，你看问题，并说：“我知道如何find一个数组中的元素？
更广泛的模式是真正的作品相同的方式。 你需要有许多不经常改变的数据结构副本 – 这使你认为“享元”。 你想要一个生活在networking边界两边的东西，你认为代理。
当你学习模式，特别是GoF时，问自己：“什么情况需要这种模式？我以前看过这种模式吗？在以前的工作中我可以用什么？在哪里可以find我自己人生中的一个例子？ “
有一个基本模式的核心概念，大多数人不喜欢。 不要把它们当作数据结构或algorithm。
相反，把你的代码看作是发送消息的人，比如通过笔记或者发送信件给对方。 每个对象都是一个“人”。
你组织“人员”的方式以及他们用来发送消息的模式是模式。
devise模式？ 你在浸泡他们！
devise模式没有什么特别之处，它们只是devise模式。 所有的开发使用devise模式。 面向对象程序devise中有一定的devise模式，被认为是普遍可取的，并已成为规范的devise模式。 但也有许多不受欢迎的或其他不重要的devise模式（如devise反模式 ）以及未被发现和/或未被logging的模式。
编程时无法避免使用模式。 但是你可以更加意识到你正在使用的模式，以及某些模式是有用还是不适用的时候。 从GoF书籍中学习规范devise模式将会有所帮助，同时学习代码气味和重构 。 对于什么时候应该使用特定的devise或devise模式，没有一个正确的答案，您需要积累使用和实施的经验，以便知道何时何地使用哪种模式。
经验。 了解他们使用的模式和现实世界的例子。 每当你做出devise决定时，都要考虑一下你知道的模式是否适用于它。 随着时间的推移，你会变得更好，你会发现新的方法来将这些模式应用到更广泛的问题上。
我发现的另一本很棒的书是：
重构模式
通过显示何时，何地以及如何将现有代码更改为模式，使我对这些概念有了更好的理解，并能够确定可以使用的地方。
Rian van der Merwe在2012年6月为Smashing杂志写了一篇很好的文章 。这里有一些突出的要点。
devise模式是有用的，有两个原因：
- 模式节省时间，因为我们不必解决已经解决的问题。
- 模式使得Web更易于使用，因为随着devise师的采用越来越多，用户习惯了事物的运作方式，从而减less了他们在遇到通用devise元素时的认知负荷。
van der Merwebuild议我们在下列情况下考虑破坏模式：
- 这种新的方法在经验上提高了可用性，或者
- 既定的方式已经过时了。
如果你知道这些模式，那么他们就成了你工具箱里的工具。 当你看一个任务，你从你的工具中select。 在这一点上，你应该有一个相当好的主意，哪个工具是最适合给定问题的。 这是公式停止工作，你实际上做工程工作。
你怎么知道什么时候使用if语句？
我把它比作那个，因为它是一个更大的构造，在你能够有效地使用它之前，你需要知道它的来龙去脉。 if语句解决了一类需要分支的问题。 桥梁模式解决了一类问题。 我真的不认为他们有任何不同。
我同意只学习模式是不够的。 大多数书籍的问题是，他们没有提供现实世界的例子。 我听说，正如一些人之前所build议的，头一个devise模式是一个很好的模式。
另一件事是，大多数书是故意不是语言特定的 ，这可能是一个好事或坏事。 然而，重要的是理解一个模式， 知道如何很好地实施它同样重要 。 我遇到了一本名为“ C＃3.0devise模式 ”（ C＃3.0 Design Patterns）的书，其中对这两个不可分割的方面进行了大致相同的描述。
当我第一次遇到devise模式时，我也有同样的问题。 我赞赏这些概念，但不知道何时或如何应用它们。 我最初的做法是在devise阶段寻找适用性。 一旦你获得了每个区块的框图和半明确的职责，就不难承担起责任，并用一本体面的参考书来交叉引用它们。 这里提到了几个好的，但是GoF应该在你的名单上。 下一步是根据您在模式中看到的内容来寻找devise方面的改进。
devise模式的概念已经从结构工程中获得，就像软件工程中的许多实践一样。 如果考虑build立一个结构体系，那么就需要就如何build立这个结构体系来实现所设定的目标作出决定。 在做出这些决定时，您将有一系列的要求。 它可能是一件简单的事情，桥一定能够一次支撑X吨，或者具有特定的拉伸强度以允许在风中足够的移动等。build筑师将使用其他构build的先前知识来做出这些deviseselect。 他/她将不太可能从头开始尝试解决问题。
软件工程和devise模式是完全一样的。 他们只是常见问题的常见解决scheme。 如果你知道devise模式，那么当你正在devise一个devise模式时，系统的特定部分需要符合你devise模式的东西，然后使用它。 不要尝试围绕devise模式安装系统，将devise模式与系统（适合的地方）相匹配。 试着把它们看作是一套解决scheme，以减less你需要做的devise工作，并且谨慎地devise你的解决scheme，以便尽可能多地devise模式。 这只会使您的解决scheme无法维护，可能相当麻烦。
devise模式是如何解决常见问题的一般说明 。 有两件事情我们应该注意：
首先，这是一个通用描述 ; 这不是一个具体的解决scheme，它也不是一个完整的配方，它只是一个解决scheme如何看待，以解决一个共同的问题的描述。
第二，问题是一个常见的问题：这意味着这个问题以前曾经遇到过很多次，随着时间的推移，人们开发了一个理想的解决scheme如何应用于这个常见问题的描述。
所以，如果遇到一个不常见的新问题，尽量不要使用devise模式来解决问题，或者至less不要让devise模式成为解决您所面临的任何问题的工具。
