是否有固定的设计模式,或者每个足够熟练的软件开发人员是否识别并减少他们的代码以开发新的模式。有效地创建自己的“设计”模式。
编辑 - 感谢您的回复。实际上,我只是重构和/或减少在编写代码之前应该首先将问题与现有设计模式进行比较的代码。如果找到匹配项,那么我应该使用它,否则我只是重构代码(这不是一件坏事,通常不会产生任何新的普遍有用的“模式”。)
是否有固定的设计模式,或者每个足够熟练的软件开发人员是否识别并减少他们的代码以开发新的模式。有效地创建自己的“设计”模式。
编辑 - 感谢您的回复。实际上,我只是重构和/或减少在编写代码之前应该首先将问题与现有设计模式进行比较的代码。如果找到匹配项,那么我应该使用它,否则我只是重构代码(这不是一件坏事,通常不会产生任何新的普遍有用的“模式”。)
这不是一个非此即彼的问题。
设计模式是常见问题的通用解决方案。
已经有一堆现有的设计模式,每一个都适用于不同的问题(或不同的上下文),但设计模式的规范并没有关闭。当然还有更多的模式需要创建和/或发现。
要记住的重要一点是,要使解决方案真正成为一种模式,它需要足够通用才能被重用,并且需要应用于重复出现的问题。
我认为随着时间的推移,大多数程序员都会独立发现许多相同的模式。设计模式目录的真正目的是让我们都可以一劳永逸地同意特定模式是什么和做什么,例如外观模式,然后在更高的抽象层次上讨论它。
如果您阅读有关设计模式的文献,您会发现它是一个涵盖至少以下几种知识的总称:
常见问题的解决方案
每个程序员都应该知道的有用的编程技术,即应该普遍使用的
常用语言中丢失的解决方法(与 Smalltalk 相比,最初的四人帮一书包含许多 C++ 中丢失的解决方法)
设计模式的另一个重要方面是它们为程序员提供了一个通用的词汇来讨论这些事情。因此,要成为一种设计模式,必须在社区之间共享某些东西并获得一致同意的名称。要回答您的问题,您可能会创建一个新的设计模式,但首先要创建一些新的东西,然后让社区同意它是值得的(以及如何称呼它),需要做很多工作。
当然,新问题将变得普遍,有用的新编程技术将被发明,新的损失将产生对新解决方法的需求。但这不会经常发生,并且发明新的解决方案将是大量的工作。《四人帮》几乎完全是对现有实践的编纂——这本书的主要新贡献是共享词汇。这是一项有价值的贡献,但让我们这些听到炒作并希望得到的不仅仅是新瓶装旧酒的人感到失望。
如果您想创建新的设计模式,请留下人迹罕至的路径。例如,模式在面向对象的世界中几乎无处不在。(尽管围绕多方法调度或基于原型的语言可能仍有机会使用模式。)相比之下,函数式程序员仍在等待有人识别和命名大多数常见的解决方案和良好实践。如果你是一个伟大的思想家和作家,你可能会对那个领域产生巨大的影响。
在您(1)多次需要它之前,它不是“模式”;(2) 可以以独立于特定问题域的方式对其进行描述。
也就是说,如果我按照自己的方式行事,我会宣布暂停使用新模式,或者拥有一个官方模式语言存储库,在它被记录、同行评审并证明不重复之前,它不会成为“模式”现有的模式。
大多数情况下,当人们谈论“组成一个模式”时,他们的真正意思是他们找到了一个他们想要重用的代码片段。
肯定有固定的、公认的模式,正如“四人帮”的设计模式一书很好地阐述的那样。微软模式和实践团队等团队也发布了CAB和SCSF等模式。这是否意味着每个模式都被覆盖了?当然不是。开发人员和团队经常提出自己的模式来满足他们的需求并在整个项目中使用。
所以我们不想重新发明轮子——使用已经存在的模式——但不要觉得你被限制在别人正在做的事情上。
没有理由不能将自己的模式和反模式记录下来,作为与他人分享所学知识的一种方式;然而,每个足够熟练的软件开发人员都不太可能真正发现尚未在其他地方发现和记录的东西。在发布这样的模式之前,一定要确保另一个模式还没有涵盖这种情况,以免以后出现尴尬。
设计模式的主要用途之一是与其他程序员交流设计的方法。如果您创建自己的,那么只有您会意识到它们,并且它对于交流没有那么有用。
通常,开发人员确实会创建我们自己的设计模式,将这些与已发布的模式相关联会给我们带来新的想法和见解,并提高我们的沟通能力。
如果你发现自己在一个有很多极端抽象机会的大项目中工作,你可以而且很可能会这样做。
但是,一般来说,设计模式是由那些花时间研究大型软件开发的人创建的,他们来自许多自己和他人的项目。
软件设计模式通常适用于重复出现的问题,而不是特定于项目的。如果您为自己的问题域找到的解决方案足够通用且可重用以用于具有类似问题的类似项目,则它们可能会被视为模式。
随着软件开发出现的问题需要越来越多的解决方案,模式存储库不断增长。