何时使用哪种模式？

Question

作为一名初级开发人员,我对某些设计模式有点困惑.有时,我只是不知道在哪个环境中使用哪个.

例如,在创作模式上,我真的不知道何时使用:

实际上,我看到了一些差异; 但我也看到你可以使用多种解决方案,如:

我的意思是,这些创作的结果最终是相同的:你得到你的对象实例.

我只是想知道你会在不同的环境中使用什么样的设计(我想它可能取决于性能需求,对象的复杂性,耦合......)

此外,我没有看到外观和中介之间的巨大差异,除了中介调用不同的接口.

对于责任链,我不明白为什么我看到所有实现使用链式列表.这个模式不能用我们连续调用的简单处理程序列表来实现吗？

这就是为什么我希望人们告诉我你将使用GoF模式的具体情况,以及为什么你不会使用任何其他可能适合给定问题的模式(但可能不那么优雅) ).

谢谢

Answer 1

像我第一次遇到设计模式时的许多人一样,我意识到很多人只是我用来解决设计问题的机制的名称.首先是问题,然后是解决方案.我从不接近设计模式,就像它们是需要适合某个地方的拼图一样.

您并不是真的需要回答模式名称的问题,就好像它是考试一样.这样做的方法是坐下来思考您的代码需要做什么以及将来如何改变.这就是我们如何使用这些设计模式的方法.人们一直使用相同的技巧解决一系列问题,直到最终有人出现并给出了这些技巧.

您遇到的唯一问题是缺乏经验,而且无法通过SO来解决.当你编写软件时,你总会遇到一些错误.你会发现,如果你以这种方式做事,他们会更好.顺便提一下,这种方式有一个名字; "抽象工厂","适配器","观察者",等等.将来你会知道何时以及为何使用它.现在记住KISS原则.不要使不必复杂的事情复杂化.

在了解如何使用它们之前了解设计模式这一事实意味着您比大多数开发人员领先一步.不要过多地冒汗,只要记住,下次遇到问题时,其中一个可能是可接受的答案.渐渐地,你会发现什么时候应该使用设计模式,什么时候不应该使用.

专门针对"你并不是真的需要回答一个模式名称的问题,好像它是一个考试" (6认同)
+1代表*"只是我已经使用的机制的名称".*模式不是你必须使用的.有人只是决定花时间写下所有的解决方案并且一遍又一遍地"发明" - 并命名它们.通过阅读GoF,您可以开始"发明"自己的解决方案 - 它可能已经发明了.它们可能已经很明显,但现在它们有一个名字. (3认同)
给KISS +1(xtra chars) (2认同)