设计模式是你自己发明的吗

这不是一个非此即彼的问题。

已经有一堆现有的设计模式,每种模式都适用于不同的问题(或不同的上下文),但是设计模式的标准并不是封闭的。当然还有更多的模式需要创建和/或发现。

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

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

至少包括以下知识:

• 常见问题的解决方案

• 每个程序员都应该知道的有用的编程技术,也就是说,应该是通用的

• 在常用语言中,对于丢失的解决方案(四本书的原始组包含了许多C++中的损耗的处理方法,比方说SMALLATE)

设计模式的另一个重要方面是它们给程序员 常用词汇 感谢你谈论这些事情。所以,要成为一种设计模式,必须要有一些东西 社区共享 并被给予 约定名称 您可以创建一个新的设计模式 ,但首先要做的是大量的工作 创造新事物 ,然后得到 它是值得的(以及如何称呼它)。

这种情况不会经常发生 而发明新的解决方案将是一项艰巨的任务 大量的工作 . 《四人帮》一书几乎完全是对现有实践的编纂——该书的主要新贡献是共享词汇。这是一个有价值的贡献,但对我们这些听到炒作,并希望在新瓶装的旧葡萄酒以外的东西失望。

如果你想创造新的设计模式, 留下人迹罕至的道路 函数式程序员仍在等待

当然也有固定的、公认的模式,正如 "gang of four"'s Design Patterns book CAB 和 SCSF 像微软模式和实践团队发布的。这是不是意味着每一种模式都涵盖了?当然不是。开发人员和团队通常会提出自己的模式来实现他们的需求,并在整个项目中使用。

因此,我们不想重新发明已经存在的车轮使用模式,但不要觉得你只局限于其他人正在做的事情。

也就是说,如果我有办法的话,我会宣布暂停使用新的模式,或者有一个官方的模式语言库,在它被记录、同行评审并证明不会复制现有的模式之前,它不会成为一个“模式”。

你没有理由不记录你自己的模式和反模式,以此与他人分享你所学到的东西;然而,每一个足够熟练的软件开发人员都不太可能真正发现一些在别处还没有发现和记录的东西。在发布这样一个模式之前,一定要确保另一个模式还没有涵盖这个案例,以避免以后的尴尬。

通常开发人员会创建我们自己的设计模式,将这些模式与已发布的模式联系起来会给我们提供新的想法和见解,并提高我们的沟通能力。

但是,一般来说,设计模式是由那些花时间从大量自己和他人的项目中研究软件开发的人创建的。

http://en.wikipedia.org/wiki/Design_Patterns