我是一个迷茫的新手和业余程序员,试图掌握这一点,所以请原谅我的问题有点小或没有太大的意义。
我看到很多关于SO的问题都围绕着设计模式的使用,我想知道是否有人拥有学习和实现设计模式的良好资源?我了解一般的想法,并且知道如何/何时使用其中的几个(Singletons,Factory方法),但我知道我错过了。
(只要有关系,我的首选语言是C#,但我可以从其他语言的示例中学到)
Answers:
设计模式之所以出色,有多种原因:
但是,当您的目标只是学习设计模式时,我认为您缺少基本知识。所有设计模式都基于更通用的原则。高内聚,低耦合开闭原理,DRY,李斯科夫替代原理等。对于这些基础知识,我将按以下顺序阅读以下书籍:
之后,您就可以准备四种设计模式的基本组合
下一步:
并永远记住:模式不是目标!
C#3.0设计模式,以C#透视设计模式。
(来源:oreilly.com)
我建议您看一下Jean Paul Boodhoo关于DNRtv上的Demystifying Design Patterns的方法论(?),以下提供了URL。该视频广播涉及到Singleton,Abstract Factory等-区别在于您可以在他讨论理论的同时观看他的代码。很高兴在一个下雨的工作日看午餐。
http://www.dnrtv.com/default.aspx?showNum=63 http://www.dnrtv.com/default.aspx?showNum=65 http://www.dnrtv.com/default.aspx?showNum= 68 http://www.dnrtv.com/default.aspx?showNum=71 http://www.dnrtv.com/default.aspx?showNum=92
以上注释的注释。
GOF模式快速参考
在这里可以启动dofactory.com/patterns/patterns.aspx是一个好地方-您可以找到每个模式的链接以及相应的实现。
但是,请记住,这些都是GOF模式。在OOAD获得足够的专业知识后,您可能还需要阅读和理解高级模式。Head First设计模式是一个好的开始,在取得一些进展之后,请使用Martin Fowler的企业应用程序体系结构模式。
应用设计模式-思考过程
另一个主要方面-应用设计模式与了解它们一样重要。阅读这些文章可能对您也有帮助。
希望这可以帮助
在花钱买书之前,我会推荐Wikipedia出色的设计模式页面。也适用于其他与Google不同的东西,用于“设计模式截屏”或在YouTube上搜索“设计模式”。以不同的方式呈现相同的信息通常有助于减少一分钱。
《四人帮》一书是有关最著名的模式的权威文章,但阅读起来并不容易,并且使用C ++示例并不是每个人都喜欢的。
该Head First设计模式的文字是更为接近,但只包含四种模式岗的一个子集。
最重要的是了解特定模式在何处以及为何有用。然后,以您选择的语言在网络上搜索实现示例,然后进行实验,直到您“理解”为止。在继续学习下一个模式之前,请先了解其中一种模式。每个人都比其他人更了解某些模式(还有数百个鲜为人知的模式)。
只是不断插电。
设计模式就像任何库函数一样,请阅读它们,然后在出现问题时,设计模式将出现在“工具箱”中。有许多设计模式书籍,都是按照原始的“四人帮”设计模式进行仿制的。
对于任何程序员来说,我认为和Fowler的Refactoring本书都是绝对的最低要求。
对于网站,非常好的网站是http://ajaxpatterns.org,来自ajaxian网站的开发人员之一
原始的《设计模式》一书是所有程序员必读的书。
这是一本非常出色的书籍,涵盖各个层次:布局,清晰度,洞察力,深度。这是一本很棒的书,您首先要从头到尾阅读,然后用作参考,直到您从内到外真正地了解它。
您可以从Wikipedia页面开始,但也可以阅读一本好书。
对于一个很少经验的人来说,深入研究设计模式对我来说没有太大的意义。很高兴知道它们的存在,但是在这一点上,您应该更多地专注于其他事情,而不仅仅是学习设计模式。
它们在遇到问题时很有用-作为新手/初学者开发人员的概念,除了知道您应该在任何时间和地点使用它们之外,它们实际上并没有太多实用价值。
编辑要澄清-许多设计模式是某些领域中发现问题的结果。很难指望新的程序员(IMO)知道用于某些问题的设计模式。正如我们在CS研究中散布算法一样,我们需要了解我们可以使用模式做的事情及其好处,但是当人们仍在建立问候世界或发现stl时,对设计模式的实际需求就不大。模式很棒。但是它们不是灵丹妙药。
(CASE(工具)也不是,UML也不是,SCRUM也不是,TDD,STL,Java或XML等都不是。)这些都是我们专业的方面,因此将这些主题视为第二主题。来是天真。
模式包括程序员用来谈论抽象设计的高级词汇。如果您正在重复使用抽象解决方案,则按名称引用它会很有帮助。如果您发明了一种模式,则进行一些检查以确保尚未获得名称是很专业的。如果已命名,则说明可能会有用。
在进行了一点点编码之后,您会发现自己编写的代码与之前编写的代码相似。这是一个模式。即使是很小的模式,也应注意。有没有更好的模式?您是否看到某些微小的模式合作解决更大的问题?好吧,下一次,当您想解决更大的问题时,整个模式将成为一个整体。整理详细的代码行变得机械化。
您越注意到模式,编程就变得越容易,您就越会欣赏其他程序员开发出的一些最大最好的模式。尝试掌握MVC模式。一种或另一种方式,即使在很小的设计决策中,变化也随处可见。