学习设计模式时候的一点感悟

[zjpixyniannian]

看了不少相关的书籍,文章,现在水平仍然很低,主要是实践不够多,慢慢来吧,我也不求一口吃个胖子.

但是有一点,我从书籍中看来的,觉得有一定道理,就是不能为了应用设计模式而且在程序中用,而是应该

通过对程序的涉及,代码的重构,使代码逐渐趋向某种模式.不知道大家认为对不对?

[yufeng1979]

曾经看了一篇文章,其中有一句对学习设计模式的评论:开始是见山不是山,见水不是水;接着是见山是山,见水是水;而最高的境界还是是见山不是山,见水不是水.说的就是开始时看到运用了设计模式的代码不知道运用了设计模式,等自己有了一定使用设计模式的经验时看到运用了设计模式的代码知道运用了设计模式,然而当你在编写代码时已经不知不觉的运用了设计模式时才是学习设计模式的最高境界

[merlinran]

殊途同归。每个人有不同的领会办法

[aweto]

一种模式只是解决某一类设计问题经验的累积。

[peakpanda]

在中国能用到模式的太少了。小公司用不上，国内大公司用不好，外企做不上。
国内小公司由于人才吸引力，项目稳定性，小公司的急功近利根本就不会用设计模式。
多数国内大公司由于虽然名声在外却烂透了的管理体制以及用人制度和官僚主意也根本没有土壤用好设计模式。而外国大公司几乎不会把系统架构拿到国内来做。
看来只有国外中小公司的机会比较大。

并且中国人的思维模式并不适合用设计模式。
我觉得，设计模式至少要有以下土壤：较低的人员流动，人员在某一领域的较长专攻，软件人员较长的技术寿命。一代一代人带出来的人是很像的，很多无奈之下的经理带出的程序员简直叫人痛心。新的一代由于有过多的工具和支持技术，对面向对象有较深的理解本就不容易，个人再不努力，就很难有所成了。我很痛心，接下来的一代很多人身上很清晰的体现出两个字：浮躁！说得远比做的多，吹得比实际能力高出不知多少。没多少能力就四处招摇撞骗，腔调足的不得了，就是缺乏可行性。人才市场中如果没有较细节的考察或较高的淘汰率，十有八九招来的是棒槌。
以上言论有些激烈，有追求的程序员们别介意，有什么想法的，欢迎讨论。

[zengwujun]

up

[suyun9329]

up

[uoyevoli]

我感觉设计模式的最高境界就是：手中无模式，心中亦无模式。你就是高手中的高手了。

[moonranger]

设计模式到底是什么啊？
不懂~~~~~~~~

T_T

[beyondtkl]

ai

mk

[mythlee]

软件设计中经常遇到的问题是不确定，经常需要变更和扩展，模式的一个好处就是通过各种技巧将常见的变动和扩展模式化，将它们封装起来与系统的其他部分隔离开，以减少变动时的耦合性。模式的另一个好处是通过特殊的技巧或利用语言机制避免程序开发中出现错误。
因此从某种角度说，在设计时如果能够对变动、扩展和易犯的错误具有良好的预见性，并为之作相应的准备，实际上就达到了设计模式的目标。至于书里总结和归纳的分类模式是对实际设计和开发工作的抽象和总结，一方面为一些单纯简单的情况提供了成熟标准的处理方法，让开发人员不必重复设计，另一方面可以将它看成一些基础的学习范例，就像九九乘法表一样，背会了九九乘法表不见得就能算两位数的乘法，它是精华但不是全部。

[peakpanda]

软件设计中经常遇到的问题是不确定，经常需要变更和扩展，模式的一个好处就是通过各种技巧将常见的变动和扩展模式化，将它们封装起来与系统的其他部分隔离开，以减少变动时的耦合性。模式的另一个好处是通过特殊的技巧或利用语言机制避免程序开发中出现错误。
因此从某种角度说，在设计时如果能够对变动、扩展和易犯的错误具有良好的预见性，并为之作相应的准备，实际上就达到了设计模式的目标。至于书里总结和归纳的分类模式是对实际设计和开发工作的抽象和总结，一方面为一些单纯简单的情况提供了成熟标准的处理方法，让开发人员不必重复设计，另一方面可以将它看成一些基础的学习范例，就像九九乘法表一样，背会了九九乘法表不见得就能算两位数的乘法，它是精华但不是全部。
------------------------------------------
说得好

[merlinran]

关于预见，我有个体会，预见到的东西有90％都不会发生。所以我更倾向于从最简单的开始。但即使是最简单的程序，都必须有一个清晰的、下意识的设计，这是从问题本身出发的，而不是预见到了什么。简单两个字：抽象。

[peakpanda]

关于预见，我有个体会，预见到的东西有90％都不会发生。所以我更倾向于从最简单的开始。但即使是最简单的程序，都必须有一个清晰的、下意识的设计，这是从问题本身出发的，而不是预见到了什么。简单两个字：抽象。
----------------------------------------------
如果是一般的应用软件，尤其是项目对这方面的要求确实不是很高，但是如果是一个framework的话就不同了。而且如果软件的使用周期长，用户多，版本升级频繁，那么就一定要考虑了。

[beauty2004]

赞同peakpanda的说法

[qutr]

我的感觉是学习运用设计模式，必须要有实际的开发经验。当你不会（或没有学过）设计模式时，其实你就在有意无意的用着某些模式，但是不像书上说的那样用的是标准形式。一旦开始学设计模式后，就要不断的回忆自己做过的项目，然后用书上讲的理论去试者修改，看能不能得到更好的设计和结构。本人也在学习中，一点感受和大家交流。望指教！！！

[xt_jat]

就我的经验，基本同意你的观点，有时候，你能一眼看出来，解决某个问题用某个模式比较合适，比如Unod redo 用command模式， 但有些时候你并不能一开始就知道用某种模式， 那就只能不断重构，在某一天，你就会发现，它逼近某个模式了

[Android]

如果你习惯性的使用虚函数，就说明你对模式有一定的理解了

[chon81]

yifengling0(逸枫) ：极限编程是要求先用最简的方法解决问题，然后再不断的重构。不是你说的一开始就用进模式吧。
peakpanda(圆圈)：小公司不会用不上吧，除非他们只写helloworld程序(我见过一个用了4种设计模式的helloworld程序)。

很多人都把模式当做概念了。一定要把模式死套在一段代码吗才行。
我觉得，模式只是一种经验，是前人总结出来的一些经验。模式并不只《设计模式》里的23种，还有很多如MVC,NullObject了，这些就不是在那23种里面。人们在开发过程中不断的总结，不断的发现更多的模式。
其实在我们写的代码中就经常无意识的引入的模式。
模式的应用不一定要一开始就要在设计中引入，往往会用更直接的办法去设计，然后不断的重构，不断的引入模式。
模式的引入是为了使代码更灵活，但是如果一开始就引入模式会增加设计的复杂度。

[peakpanda]

yifengling0(逸枫) ：极限编程是要求先用最简的方法解决问题，然后再不断的重构。不是你说的一开始就用进模式吧。
peakpanda(圆圈)：小公司不会用不上吧，除非他们只写helloworld程序(我见过一个用了4种设计模式的helloworld程序)。

很多人都把模式当做概念了。一定要把模式死套在一段代码吗才行。
我觉得，模式只是一种经验，是前人总结出来的一些经验。模式并不只《设计模式》里的23种，还有很多如MVC,NullObject了，这些就不是在那23种里面。人们在开发过程中不断的总结，不断的发现更多的模式。
其实在我们写的代码中就经常无意识的引入的模式。
模式的应用不一定要一开始就要在设计中引入，往往会用更直接的办法去设计，然后不断的重构，不断的引入模式。
模式的引入是为了使代码更灵活，但是如果一开始就引入模式会增加设计的复杂度。
--------------------------------------------------------------------
呵呵，是不是极限编程不重要，关键是你怎样将一件事情做好。模式是前人的经验，是对我们思考的一个指引。不管你采用什么开发模型，把事情尽可能考虑在前边没有错。极限编程也不是对开始可以考虑清除的东西和未来可能出现的东西视而不见，只是需求不明确，时间短的特性下的一种平衡。
我是用户我不管你的helloworld用了少种模式，你能实现我的所有需求就是好的helloworld.
BTW，MVC是设计更高层次的抽象，很多种模式或模式的组合都可以实现它。

[huaqianshu]

up