设计模式是你在实践中发明的吗?

3
是否存在固定的设计模式,还是每个足够熟练的软件开发人员都能识别和简化他们的代码以开发新的模式。有效地创建自己的“设计”模式。
编辑-感谢回复。实际上,我只是在重构和/或减少代码,应该首先将问题与现有的设计模式进行比较,然后再编写代码。如果找到匹配项,则应使用它,否则我只是重构代码(这并不是坏事,并且通常不会产生任何新的普遍有用的“模式”)。
8个回答

7

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

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

已经存在许多设计模式,每个模式都适用于不同的问题(或不同的上下文),但是设计模式的规范并没有封闭。肯定还有更多的模式需要被创造和/或发现。

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

我认为大多数程序员随着时间的推移会独立地发现许多相同的模式。设计模式目录的真正目的在于,我们可以最终一致地认识到特定模式的功能,例如外观模式,然后在更高的抽象层次上讨论它。


在特定的上下文中,经常遇到问题。在错误的上下文中应用模式就像是把锤子看成一切都是钉子。 - Chris Cleeland

6
如果你阅读了有关设计模式的文献,你会发现它是一个涵盖以下至少几种知识的“大伞”:
- 常见问题的解决方案 - 每个程序员都应该掌握的有用编程技巧,即应该普遍使用的技巧 - 常用语言中出现问题时的解决方法(原始的四人帮书籍中包含许多针对 C++ 中的问题的解决方法,相比之下 Smalltalk 就不会有这些问题)
设计模式的另一个重要方面是,它们为程序员提供了一个共同的词汇,以便谈论这些事情。因此,要成为设计模式,某些东西必须在社区中得到共享,并被赋予一个约定俗成的名称。回答你的问题,你可能会创建一个新的设计模式,但首先要做很多工作来创建新的东西,然后让社区认可它的价值(以及如何称呼它)。
当然,新问题将变得常见,有用的新编程技术将被发明,新的问题也将创造出需要新的解决方法。但这种情况不会经常发生,而且发明新的解决方案需要大量的工作。四人帮书籍几乎完全是对现有实践的编码,书籍的主要新贡献是共享词汇。这是一个有价值的贡献,但对于那些听到炒作并希望得到比老酒装在新瓶子里更多的东西的人来说,这是令人失望的。
如果你想创建新的设计模式,请离开已经走过的路。例如,在面向对象世界中,模式几乎已经成为老生常谈的话题。(虽然可能还有一些围绕多方法调度或基于原型的语言的模式的机会。)相比之下,函数式编程人员仍在等待有人确定和命名大部分常见的解决方案和良好的实践方法。如果你是一位伟大的思想家和作家,你可以对该领域产生巨大的影响。

2
“有一些已经被确定和认可的模式,就像《四人帮设计模式书》中所描述的那样。还有一些模式,例如CABSCSF,由微软的模式和实践团队发布。这是否意味着每个模式都已经覆盖了?当然不是。开发者和团队通常会想出自己的模式,以满足他们的需求,并在整个项目中使用它们。
因此,我们希望不要重复造轮子-使用已经存在的模式-但不要感到受制于别人正在做的事情。”

2
直到你在多个场合需要它并且能够用独立于特定问题域的方式描述它,它才算是一个“模式”。
话虽如此,如果由我决定,我会宣布禁止新的模式出现,或者设立一个官方的模式语言库,在文档化、同行评审和证明没有重复现有模式之后才成为“模式”。
通常,当人们谈论“编写模式”时,他们实际上是指他们找到了一个想要重用的代码片段。

1

你完全可以记录自己的设计模式和反模式,以此与他人分享你所学到的知识。但是,很可能每个技术娴熟的软件开发者都不会发现一些之前没有被其他人发现和记录过的东西。在发布这样的模式之前,请确保没有其他模式已经涵盖了这种情况,以避免日后尴尬。


1
设计模式的主要用途之一是与其他程序员交流设计想法。如果你创建自己的设计模式,只有你自己知道,对于交流来说不太有用。
通常开发者会创建自己的设计模式,将其与公开的模式联系起来可以给我们带来新的想法和认识,并提高我们交流的能力。

0

如果你发现自己正在处理一个有很多极端抽象机会的大型项目,那么你可以并且可能会使用设计模式。

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

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


0

软件设计模式通常适用于经常出现的问题,而不是特定于项目。如果您为自己的问题域找到的解决方案足够通用且可重复使用,那么它们可能被视为模式,并可在类似的具有相似问题的项目中使用。

随着软件开发中需要越来越多的精心设计的解决方案,模式库也在不断增长。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接