设计模式是否是你发明的东西

是否设置了设计模式,或者每个人都是足够熟练的软件开发人员是否认识并减少了他们的代码以开发新模 有效地创建自己的"设计"模式.

编辑 - 感谢您的回复.实际上,我只是重构和/或减少代码,在编写代码之前,应首先将问题与现有设计模式进行比较.如果找到匹配,那么我应该使用它,否则我只是重构代码(这不是一件坏事,通常不会产生任何新的通常有用的"模式".)

这不是一个或两个问题.

设计模式是常见问题的通用解决方案.

已经有一堆现有的设计模式,每个模式都适用于不同的问题(或不同的上下文),但设计模式的规范并未封闭.肯定会创建和/或找到更多模式.

需要记住的重要一点是,对于真正成为模式的解决方案,它需要足够通用以便重用,并且需要应用于重复出现的问题.

我认为大多数程序员随着时间的推移会独立发现许多相同的模式.设计模式目录的真正目的是使我们能够一劳永逸地同意特定模式的特定模式,例如外观模式,然后在更高的抽象层次上讨论它.

如果您阅读有关设计模式的文献,您将看到它是一个涵盖至少以下类型知识的总称:

解决常见问题

每个程序员应该知道的有用的编程技术,即应该是常用的

常用语言中的损失的解决方法(最初的Gang of Four书中包含许多C++中的损失的解决方法,比如Smalltalk)

设计模式的另一个重要方面是它们为程序员提供了一个用于讨论这些事情的通用词汇.因此,要成为一种设计模式,必须在社区之间共享某些内容并获得一致同意的名称.要回答你的问题,你可能会创建一个新的设计模式,但是首先要创建一些新的东西,然后让社区同意它是值得的(以及称之为什么)是很多工作.

当然,新问题将变得普遍,有用的新编程技术将被发明,新的损失将产生对新的解决方案的需求.但它不会经常发生,发明新的解决方案将是一项大量的工作."四人帮"一书几乎完全是对现有实践的编纂 - 本书的主要新贡献是共享词汇.这是一个值得贡献的,但是对于我们这些听过炒作并且希望在新瓶子里有更多旧酒的东西的人来说,这是令人失望的.

如果要创建新的设计模式,请保留良好的路径.例如,在面向对象的世界中,模式几乎无处不在.(尽管围绕多方法调度或基于原型的语言仍然存在模式的机会.)相比之下,功能程序员仍在等待某人识别和命名大多数常见解决方案和良好实践.如果你是一个伟大的思想家和作家,你可能会对这个领域产生巨大的影响.