什么是基于模式的编程？

有人可以解释编程中对模式和反模式的痴迷吗？我问是因为我完全不知道任何模式的含义。面对编程任务时，我会稍微考虑一下该问题，写下一些我认为相关的数据结构，为解决方案提供原型，分离出一些模块并进行迭代。在此过程中，我认为“哦，我这里需要FunkyLookyTastic模式”无处不在。

模式是解决常见类型问题的常用方法。仅此而已。通过了解和理解它们，您可以利用其他人的经验来指导您迈向证明有效的解决方案类型，避免过去遇到的陷阱，并使用其他人熟悉的术语讨论解决方案知道那个模式。

当然，您可以在不显式使用模式的情况下提供一个好的解决方案，而通过尝试应用一种并不真正适合您的特定问题的模式，同样可以提供一个不好的解决方案。我认为您观察到的“痴迷”通常来自刚刚发现该概念的人，并认为它比实际功能强大得多。大多数人会很快意识到它们是什么：一种有用的工具，而不是魔力弹。

另一方面，反模式是通常会降低代码质量的行为。再次，了解和理解其中的一些是很有用的，这样您就可以避免这种行为，并在他人中观察到它时尝试纠正它（使用合理的论据）。有些人会将模式的过度使用描述为反模式。

模式既是菜谱中程序员的提炼知识，又是程序员进行交流的有用方式。

正如其他答案所暗示的那样，模式实际上是常见问题的通用解决方案。好处是，在开始编码之前，您通常可以使用现有模式来获得更好的解决方案，或者发现可能的陷阱。

另一个好处是当您与某人谈论您的代码时。模式是另一种术语，将冗长的描述压缩成几个词。尝试解释“然后我们有一个由工厂添加的观察员”，而不要参考模式。您可以做到，但是要花很长时间。

大多数开发人员都会畏缩于出现的任何新范式或方法。当我第一次听说设计模式时，我就这么做了。顾名思义，设计模式就是：设计或模板，用于以可预测的方式创建类并对其行为和交互进行建模

看房子。它们有一些相似之处。每个房子都有起居室，厨房，卧室，浴室，厕所最少。没有人会建造没有浴室的房屋，对吗？公寓的模式不同于平房。城堡的模式完全不同。衣服也有图案。夹克和正式衬衫的基本设计相同，但行为却不同：面试时您不会穿牛仔夹克。类似地，可以根据类及其行为将其行为和设计分组。查看行为中的常见元素，可以为您提供类的设计模式。

我理解的设计模式仅在可重用性和可扩展性是主要关注点时才重要。如果您创建小型应用程序（例如少于10个类），则可能根本不需要它们。但是大型项目，特别是那些拥有大型团队工作，维护和功能添加周期长的项目，肯定会需要模式。在大型项目中，这甚至不是一个选择。

看看一些有关模式的在线教程。维基百科上有很多文章。这个站点也很好：http : //sourcemaking.com/。如果您是一位经验丰富的程序员，您会发现您遇到了几种模式，甚至可能自己实现了类似的功能，而没有用特定的名称知道它。

不要完全忽略它们！如果不是现在，您将来可能会发现它们很有用。持开放态度对待设计模式的关键是要问：“如果不使用设计模式会发生什么？” 模式并不意味着“治愈”（尽管您可以将它们用作解决问题的方法）。相反，他们体现了“预防胜于治疗”的格言。

相同的是，我提醒您，不要在任何时候看到使用它的小小的借口就沉迷于实施模式。我在一个项目中遇到了这个问题，在该项目中，建筑师深信没有DP，该项目将是一场彻底的灾难。在一次小组会议上，工程师们进行了整个设计的转变，并指出他所建议的许多图案除了显示“哇瞧漂亮的图案”之外根本没有用。为了减少仅在需要时使用模式的位置，进行了很多说服和讨价还价。

回答的人在通常认为的“基于模式的编程”方面是正确的。我有一个略有不同的定义，我发现它与我正在做的事情更相关，并且我倾向于使用“基于模式的编程”来描述插件方法而不是计划方法。

由于我编写了jQuery插件，CMS云插件和eCommerce插件，因此从这种角度看，“基于模式的编程”意味着要研究核心技术以及存在的用例，并在统计上最相关。特别是，插件必须非常基于模式，因此它们很好地适合于编程上下文。

但是，最好是在看到多个项目上的有效用例之后再应用一种模式，这样从统计上讲，它可以有效地重用。