什么应该首先 - 设计模式或代码？

Question

我开始一个全新的项目 - 我应该看看自己的规范，决定应用哪种设计模式，或者只是想出一个组织的总体思路，并通过重构让模式有机地出现？

根据您的经验，哪种技术的效率最高，并且更有可能导致清晰优雅的代码？

我也想知道是否有设计模式没有由GoF定义，但可能同样有价值？如果是这样，有什么有用的资源来告诉我自己这些？

Answer 1

你应该有机地发展你的代码，适应模式。过早地与模式匹配可能会导致大量不适当的代码以及很多抽象层，导致设计变得模糊。见证你所看到的任何代码是在某人第一次发现模式之后编写的;-)

Answer 2

1. 找出用例。
2. 从整个现有设计模式考虑设计。
3. 开始执行。

我相信这里的主要目标是避免重新发明车轮。

PS。在你将步骤2经过几次并习惯之后，你将能够将该步骤整合到步骤3中。

Answer 3

除非模式似乎明显跳出规范，否则我不一定会尝试从GoF挑选一些东西，然后锤击问题，直到符合模式。

最好从概念上理解你头脑中不同的抽象层次，并提出一个计划（不一定是流行的设计模式）来实现它。这是你会在经验上更好的东西。虽然了解GoF模式将帮助您提高思考代码设计方面的问题的能力，但这并不意味着解决所有问题，并且人为地强制您的问题适合设计模式可能意味着不必要的复杂和混淆。

Answer 4

在开始编码之前，您应该掌握哪些模式适合该问题。如果没有，请制作原型，以便了解您想要实现的目标。然后寻找模式并丢弃原型（的结构）（并重用好位）。

Answer 5

如果我不确定我刚开始写代码。在太久之前，结构会开始乞求重构，选择几乎总是很明显。

虽然我有时受某种特定模式的启发，但它几乎总是能够让我看到正确的路径。

我也不怕燃烧和重建程序的某些部分。我很喜欢斯科特亚当斯的一句话 - “创造力让自己犯错，艺术知道要保留哪些。”有时候，正确的答案是不明显的，直到你尝试错误的方式。

Answer 6

好的建议已经在这里。回答有关除GoF书籍以外的有用模式的问题。有，你应该检查Larman的应用UML和模式，他描述了GRASP模式。

Answer 7

我不愿意花费过多的前期设计模式使用您的编码。最好只制作简单的代码，并在需要的时候用refactor towards a design pattern来最好地捕捉你的需求。

Answer 8

你应该有机地发展你的代码，适应模式。

借调！我见过的一些最糟糕的意大利面是OO C++，有很多模式。 Fluxbox几乎无法忍受;协同（V2）烧开，broils和烤给我的面条:(

和一些最美丽的代码中，我所看到的是面向对象的C，其中OO分别为两个接口和4个和20个实现。