如果我不使用软件设计模式怎么办？[关闭]

如果不使用软件设计模式，我可能会遇到什么样的问题？您能告诉我使用标准的面向对象技术进行设计的问题吗？

您错过了重点。

设计模式固有地存在于进行软件设计时，就像世界上存在的结构模式一样。即使您不知道事物的名称，您最终也会发现某些物理结构非常适合某些问题。您会发现木头/金属棒/等的三角形形状是非常稳定的结构，但仅在平面上。您会发现方砖比圆砖更具优势...

同样，某些软件结构在某种程度上是唯一的或最佳的。最终，您将找到它们并使用它们，而不管它们的名称如何。这就是设计模式的核心-它们是经验丰富的程序员无论如何都知道并使用的这些结构的名称。它使程序员能够更加统一和简洁地进行通信。它还使程序员可以更自觉地思考模式的概念。

因此，我想提出两个要点：

1. 您不能使用设计模式。
2. 由于不知道正在使用的事物的名称，您将很难在团队中工作。

那些不记得过去的人会被谴责重复过去。

除了设计提出的问题之外，您将不会遇到任何其他具体问题。随着时间的流逝，您最终会不知不觉地使用这些模式，您只是花时间自己弄清楚它们。事先了解这些图案可以使它们更容易在设计中发现，并具有许多人证明它们的主要优点。

今天开发的所有内容都主要基于先前的知识，因此忽略它是没有道理的。想象一下，今天建造一座摩天大楼，却不知道数百年前建造大教堂的人们所面临的问题。

如果不使用软件设计模式，我可能会遇到什么样的问题？

您将遇到无法编写任何软件的问题。

变量是一种设计模式。

方法是一种设计模式。

运算符（加法，减法等）是一种设计模式。

陈述是一种设计模式。

值是一种设计模式。

参考是一种设计模式。

表达式是一种设计模式。

类是一种设计模式。

...

您始终在编程中所做的一切都是设计模式。在大多数情况下，该模式已根深蒂固，以至于您不再将其视为“设计模式”。您必须学习的东西，例如“单例模式”等等，仅仅是（尚未）被烘焙为您使用的任何语言的模式。

您能告诉我使用标准的面向对象技术进行设计的问题吗？

不，我不知道这个问题是什么意思。设计模式是 “标准的面向对象技术”，这就是使它们成为设计模式的原因。设计模式是一种解决特定问题的标准技术，特别是（尽管不一定）以面向对象的语言解决。

理解设计模式的要点比将其用于文字更重要。IMO，至少在我习惯的语言范例中，有些模式是愚蠢的。IMO是一个只盲目地使用设计模式而没有真正理解设计模式的程序员，而不是想自己思考问题的程序员。但是，熟悉这些思想然后自己决定是否值得的人可能比这两个人都要强大得多。

就是说，我不知道飞行重量的意义是什么，我并不为此感到羞耻。（请参阅有关另一个很有帮助的维基百科条目的评论）

我推荐维基百科关于设计模式的条目。它非常简洁明了。对于了解为什么可能会干扰给定的设计模式非常有帮助。我个人倾向于发现最简单的方法最有用，并且不会三思而后行地修改任何模式的给定实现以适合我的需求。

他们是想法，而不是蓝图。在某些语言中，它们根本不是一个好主意。在其他语言中，正确地将它们视为克服语言设计弱点的鞭策，而这些弱点可能可以通过减少复杂性得到更好的补偿。无论如何，在决定自己的首选解决方案之前，对它们进行检查并尝试了解它们将要克服的挑战并没有什么害处。

您将面对什么样的问题？除非您是一位编程天才，但您可能已经错失了机会，并且在解决问题上花费了更多的时间，除非您已经掌握了一切。对流行的编程思想保持批判性的眼光很重要，但是了解人们认为他们正在解决的问题永远不会有任何伤害，因为这将使您自己喜欢的解决方案/方法更加清晰。

您将面临的主要问题是您将重新发明轮子。之所以将它们称为模式，是因为它们经常且以可预测的方式出现。

即使遵循设计模式，您也可能最终会得到错误的设计。设计模式是自然的，您最终将在设计中使用某些样式。您将必须非常努力不使用任何模式。没有理由谴责设计模式，更重要的是选择适合您需求的模式

您一直在使用设计模式，而没有意识到。许多流行语言的标准库在设计时都考虑了设计模式。Java的FileReader库就是一个例子，它是使用decorator设计模式设计的。现在谈论您自己的代码，您不必被迫使用设计模式（在大多数情况下）。设计模式是“解决常见问题的可重用解决方案”，这意味着它将帮助您编写更清晰，更易于维护的代码，因此您实际上要决定要避免多少使用意大利面条式代码。