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 ;
}
}
我同意仅仅学习模式是不够的 . 大多数书籍的问题在于它们不提供真实的例子 . 我听说Head First Design Patterns，正如之前的一些建议，是一个很好的 .
另一件事是，大多数书籍都是故意的，这对你来说既好又坏 . 无论如何重要的是理解一般的模式， it is equally important to know how to implement it well . 我遇到过一本名为C# 3.0 Design Patterns的书，它对这两个不可分割的方面都投入了相同的墨水 .
14 回答
设计模式应该提供一个可以解决问题的结构 . 在解决实际问题时，您必须考虑解决该问题的许多微小变化，以确定是否符合设计模式 . 特别是，您可能需要概括您的问题或其解决方案，以使设计模式适合 .
答案是，这是一门艺术 . 了解设计模式无疑是重要的一步 . 习惯这种事情的一种方法是研究设计模式的应用，而不仅仅是模式 . 查看一种模式的许多不同应用程序可以帮助您随着时间的推移更好地将任务映射到模式上 .
我强烈建议您阅读O'Reilly的Head First Design Patterns . 这解释了如何在现实世界中使用这些模式 .
我还要补充一点，不要试图设计过多的图案 . 更多，寻找模式可能有助于解决的“代码味道” .
把问题翻过来：你应该做的模式是“什么模式适合我的问题” . 考虑一个非常简单的模式，在数组中查找元素 . 在C中，它就像是
你不看代码并想“我在哪里可以使用它”，你看问题并说“我知道如何在数组中找到一个元素吗？”
更广泛的模式确实以同样的方式工作 . 您需要拥有许多不经常更改的数据结构副本 - 这会让您想到“Flyweight” . 你想要一些生活在网络边界两侧的东西，你认为是代理 .
当你研究模式，尤其是GoF时，问问自己“这种模式需要什么样的情况？我以前看过这种模式吗？我以前的工作中有什么用呢？我在哪里可以找到一个这样的例子？ “
大多数人都没有理解的基本模式的核心概念 . 不要将它们视为数据结构或算法 .
相反，将您的代码视为发送消息的人，例如传递笔记或发送信件 . 每个对象都是一个“人” .
您组织“人员”的方式以及他们用来向对方发送消息的模式是模式 .
设计模式？你在浸泡它们！
设计模式没有什么特别之处，它们只是设计模式 . 所有开发都使用设计模式 . 在面向对象的编程中存在一组特定的设计模式，这些模式被认为是通常期望的并且已经成为规范的设计模式 . 但是也有许多不受欢迎的或其他无关紧要的设计模式（例如design anti-patterns）以及未发现和/或未记录的模式 .
编程时无法避免使用模式 . 但是你可以更加了解你正在使用的模式，以及某些模式何时有用以及何时不可用 . 研究GoF book中的规范设计模式将有所帮助，并将学习code smells and refactoring . 对于何时应该使用特定的设计或设计模式，没有一个正确的答案，您需要积累使用和实现它们的经验，以便知道何时何地使用哪种模式 .
经验 . 了解其用途的模式和实际示例 . 每当您做出设计决策时，请考虑您知道的模式是否适用于它 . 随着时间的推移，您会变得更好，并且您会发现将模式应用于更广泛问题的新方法 .
我找到的另一本好书是：
重构模式
通过显示何时，何地以及如何将现有代码更改为模式，它使我对这些概念有了更好的理解，并且能够识别它们的使用位置 .
Rian van der Merwe在2012年6月为Smashing Magazine撰写了一篇关于此问题的文章 . 这里有一些重要的要点 .
设计模式有两个原因：
模式节省时间，因为我们不必解决已经解决的问题 .
模式使Web更易于使用，因为随着设计人员的采用增加，用户得到了习惯了事物的运作方式，这反过来又减少了他们在遇到常见设计元素时的认知负担 .
van der Merwe建议我们在以下情况下考虑打破模式：
新方法凭经验改善了可用性，或者
既定的方式已经过时了 .
你是如何学习何时使用if语句的？
我把它比作它，因为它是一个更大的构造，你需要知道它的来龙去脉才能有效地使用它 . if语句解决了一类需要分支的问题 . 桥模式解决了一类问题 . 我真的不会以任何不同的方式看待它们 .
如果您了解模式，那么它们就会成为工具箱中的工具 . 查看任务时，可以从工具中进行选择 . 那时你应该非常清楚哪个工具最适合给定的问题 . 这是公式停止工作的地方，你实际上是在做工程工作 .
我同意仅仅学习模式是不够的 . 大多数书籍的问题在于它们不提供真实的例子 . 我听说Head First Design Patterns，正如之前的一些建议，是一个很好的 .
另一件事是，大多数书籍都是故意的，这对你来说既好又坏 . 无论如何重要的是理解一般的模式， it is equally important to know how to implement it well . 我遇到过一本名为C# 3.0 Design Patterns的书，它对这两个不可分割的方面都投入了相同的墨水 .
我第一次遇到设计模式时遇到了同样的问题 . 我很欣赏这些概念，但不知道何时或如何应用它们 . 我最初的方法是在设计阶段寻找适用性 . 一旦你有了每个区块的方框图和半清晰的责任，它就不太难以承担责任并与一本体面的参考书交叉引用它们 . 这里提到了几个好的，但GoF应该在你的名单上 . 下一步是根据您在模式中看到的内容寻找设计的改进 .
设计模式的概念取自结构工程，与软件工程中的许多实践一样 . 如果您考虑构建结构，则需要就如何构建该结构以实现所设定的目标做出决策 . 在做出这些决定时，您将有一系列要求可供使用 . 它可能很简单，因为Bridge必须能够同时支撑X吨，或者具有特定的拉伸强度以允许在风等中进行足够的移动 . 建筑师可以使用其他构建的先验知识来做出这些设计选择 . 他/她不太可能尝试从头开始解决问题 .
软件工程和设计模式完全相同 . 它们只是常见问题的常见解决方案 . 如果您了解设计模式，那么当您完成设计时，系统的特定部分需要适合您的设计模式，然后使用它 . 不要试图使系统适合设计模式，使设计模式适合您的系统（它们适合的地方） . 只是尝试将它们视为一组解决方案，以减少您需要做的设计工作量，并谨慎地过度设计您的解决方案，尽可能多地填充设计模式 . 这只会使您的解决方案无法维护，而且可能非常多 .
关于如何解决 common problem 的设计模式是 generic description . 我们应该注意两件事：
首先，它是 Generic description ;它不是一个完整的配方，它只是描述解决方案如何处理常见问题 .
其次，问题是问题是 common problem: ，这意味着此问题之前已经遇到过很多次，并且随着时间的推移，人们开始描述如何将理想的解决方案应用于这个通常重复的问题 .
因此，如果您遇到一个不常见的新问题，请尽量不使用设计模式来解决它，或者至少不要将设计模式作为解决您遇到的任何问题的工具 .