设计模式真的有多重要?

nop*_*ole 49 design-patterns

设计模式真的有多重要?

我认为前一代程序员并没有那么多使用设计模式(那些在80年代和90年代中期之前毕业的人).最近的毕业生一般都知道它并且使用它更多吗?

如果你有兴趣,我也做了一个调查,你可以在这里查看:

http://www.surveymonkey.com/s.aspx?sm=kJOdGX0RPx5FGrfPVm_2bmIw_3d_3d

更新:以下是初步调查结果:

http://img192.imageshack.us/img192/7107/surveyresults.png

Jav*_*ann 97

我们在80年代使用过设计模式,我们只是不知道它们是设计模式.


Mat*_*nes 61

在我看来,设计模式的最大好处是它为开发人员提供了一个讨论软件解决方案的通用词汇.

如果我说"我们应该使用单例模式实现这一点",我们有一个共同的参考点,开始讨论这是否是一个好主意,而不必先实际解决这个问题,这样你才能知道我的意思.

增加可读性和可维护性,这些解决方案可以解决常见问题,而不是每个开发人员都试图以自己的方式重复解决问题.

非常重要 可以在没有它们的情况下制作软件,但这肯定要困难得多.

  • 但是你不高兴你可以告诉人们不要以某种方式使用单身模式,他们知道你在说什么. (21认同)
  • 所以现在我们让每个开发人员都试图以同样的方式解决问题,无论他们是否合适.你提出的例子是Singleton告诉我 - 我怀疑单独的模式导致了比所有明确命名的设计模式一起导致更好的设计更糟糕的设计. (11认同)
  • Singleton模式在很多情况下可能使用得很差,但考虑到大多数人使用它的替代方案很差,将会有大量的全局变量,我认为很难将错误的设计归咎于单例模式的存在. (3认同)

Bri*_*ndy 40

它们并非绝对需要,但好处肯定超过了坏处.

好处:

  1. 代码可读性:它们确实可以帮助您编写更易理解的代码,并为您要完成的任务创建更好的名称.
    • 代码可维护性:允许您的代码更容易维护,因为它更容易理解.
    • 沟通:它们可以帮助您在程序员之间传达设计目标.
    • 意图:他们立即向学习代码的人展示您的代码的意图.
    • 代码重用:它们可帮助您确定常见问题的常见解决方案.
    • 更少的代码:它们允许您编写更少的代码,因为更多的代码可以从公共基类派生出通用功能.
    • 经过测试和完善的解决方案:大多数设计模式都经过测试,验证和完善.

坏事:

  1. 额外的间接级别:它们提供了额外的间接级别,因此使代码更复杂一些.
    • 知道何时使用它们:它们经常被滥用并用于它们不应该使用的情况.一个简单的任务可能不需要使用设计模式解决额外的工作.
    • 不同的解释:人们有时对设计模式的解释略有不同.如Ruby on Rails所见,由django与MVC看到的示例MVC.
    • 辛格尔顿:需要我说更多吗?


Mic*_*rdt 27

就我个人而言,我认为它们过于夸张且具有边际价值.这个想法听起来不错,但是当你接触它时,实际上只有少数几个常见且有用的东西值得记住(并且可能记住).

我认为他们的净影响是负面的,因为那些新近迷恋这个概念的人所犯的可怕的过度工程,并试图尽可能多地将代码塞进他们的代码中.也许更糟糕的是马斯洛的锤子效应导致糟糕的设计,因为开发人员没有找到最佳设计,而是记住了一种适合(严重)的设计模式.

  • 人们是否行使判断力或追随者与设计模式是否过度和边际价值是正交的.编程的第一条规则是:"思考".一些人是否用"使用设计模式"替换该规则与设计模式在适当位置使用时的效用完全无关. (5认同)
  • 正义,我很抱歉,但你似乎没有遇到那种喝设计模式的人,他的代码已成为你的维护噩梦.设计模式本身在正确的手中可能并不坏,但是像可疑的编程语言特征一样,它们会引起滥用,因此它们本身就是可疑的. (3认同)

duf*_*ymo 10

我见过太多"小男孩有模式"综合症.在一个人第一次阅读GoF书籍之后,它通常会受到最严重的打击,并立即跑掉,看看他们中有多少人可以融入他们正在进行的项目中.(将所有23个填入单个项目的额外要点.)他们最终得到的系统设计在其生命的一英寸范围内,无法理解或修改.

最终发烧了,他们安定下来足以适当地使用它们.但是伤害可能很大.

警示故事是"核心Java EE模式"一书.它列出了一堆解决EJB 1.0和2.0"最佳实践"的东西,现在被认为是反模式.EJB 3.0规范消除了很多它们.春天正在杀死剩下的人.

模式在阳光下度过了一天,就像UML一样.但太阳正在下降.我不认为任何一个人拯救了世界或者宣传了这个世界.


Sha*_*ell 9

我想你错过了设计模式的重点.

在软件工程中,设计模式是软件设计中常见问题的通用可重用解决方案.

因此,设计模式只是定义解决软件工程问题的常用方法的正式语言.我想大多数人都在使用设计模式而不知道它们是什么.因此,这些软件问题的常见解决方案可以追溯到很长一段时间,他们只是没有提出一种形式语言来描述他们在做什么.

我认为设计模式很重要,因为它们教你如何解决设计模式适用的领域中的问题.


Pet*_*ker 9

虽然有时谈论设计模式会很有用,但我倾向于同意那些认为它们在许多情况下有害的人.

我要提出的主要论点是,它们通常会阻止人们针对特定问题提出适当的解决方案.人们尝试将一种设计模式应用于另一种设计模式,而不是考虑如何解决该特定问题.

他们也倾向于隐藏语言缺陷.在语言表达方面,很多都是微不足道的.一个主要的例子是策略模式,它基本上以复杂的方式重新编写函数式编程.通常人们会更好地理解真正的编程原则,而不仅仅是谈论模式语言.

话虽如此:我宁愿与某人谈论模式而不是根本没有共同语言.这样,如果没有更好的选择,它们就很重要.如果我能以更正式的方式解释自己(例如代数),那么我就不再关心模式语言了.当然有些人会声称我只是发明了自己的模式语言;-)


mic*_*tan 8

重要的不是我会用的词.我会用"有帮助"这个词.为开发人员提供用于描述频繁问题/解决方案的通用语言非常有用 - 而且在协作环境中也是如此.


Lar*_*abe 7

我找到了边际价值的设计模式.任何组织良好和设计良好的软件框架都有数百种设计模式,其中很少有在正式的"模式文献"中描述.

在有设计模式之前,有一些设计良好的软件,它有许多可以在许多情况下重复使用的模式.例如,Kernighan和Ritchie关于C的书包含了一个使用yacc和lex实现的计算器的例子,以及一个堆栈,符号表,函数指针传递(即基本上是动态绑定),并包含了大量的书籍大小的模式.

通过研究Microsoft的.NET框架,Java类库等,您可以学习数百种更有用的设计模式,而不是阅读有关设计模式的书.

真的,好的软件有一个设计.如果设计很好,它可能会被重复使用.Voila - 一种设计模式.


jam*_*sls 5

我会说它们绝对是重要的。

在典型的原因(共享词汇,而不是重新发明轮子)中,它们是学习优秀软件设计的垫脚石。那里的大多数设计模式都是由具有良好面向对象原则意识的程序员开始的,他们应用他们所知道的来解决问题,并注意到其他人正在提出相同的解决方案。如果您将设计模式视为解决当前遇到的问题的食谱,那么它们并没有真正的用处,而这正是您看到“设计模式锤子”出现并使设计复杂化的地方。

相反,如果将其视为通向良好的面向对象设计的窗口,您就会开始看到它们的价值,即根据设计模式背后的原则而不是特定设计模式本身进行思考。