设计模式

你的见解是对的！不过这里是中国国内比较好的专业的j2ee论坛，高手云集。我想很多人已经熟练面向对象编程。而且是肯定的。
而且，我的看法是ooa/d以及在你眼里的狭义的面向对象编程其实是混为一体的在这些方面的提升是建立在经验的基础上的，
其实，我也是菜鸟一个

讨论模式 -> 应用模式 -> 变通应用 -> 心中无模式

>怎么这么多人讨论设计模式，很少人讨论面向对象编程实践
>感觉中国人就坏在好高骛远上了，同意的举手！

说法是错误的，设计模式==面向对象编程实践。设计模式是面向对象编程实践经验的总结。

为什么你看不到专门的面向对象编程实践？因为面向对象编程实践就在设计模式中。

只有学习设计模式，才标志你真正掌握面向对象编程，也才能实现面向对象编程实践。

补充:真是很多人有你这样的奇怪概念，所以设计模式在中国没有得到重视，J道网站当初推出设计模式专栏时，整个国内媒体包括网站还都未看到完整的GOF设计模式。 一片死寂。

原来可能大家都在想进行面向对象编程实践讨论，可惜没有入门，那些所谓的开闭原理其实对实践没有什么指导作用，已经融合在多个设计模式的中。

我之前也非常的热衷于设计模式的学习研究

现在我在发现我更需要的是面向对象编程的一些基本原则和指南，而我周围的绝大多数开发人员编写的基本对象我感觉都非常的糟糕。

例如我可以把对象的许多方法都写成静态方法当做工具来使用。但是却不知道什么时候才应该这样做。又如假设一个逻辑段放到多个对象中都是合理的，那怎么决定它应该是哪个对象的方法呢？

不好意思，第一次来，说错了大家别怪我。
感觉设计模式在软件系统的整体构架上很有用，可以帮助我们构建出更有扩展性的体统。但是现在我们大多数的时候并不是在系统设计，而是在别人已经做好的框架下编程，这种情况下，我们在人家的设计模式之中了，对于程序员来说，设计模式对于他们来说是不是并不像想象中的那么重要了，对于设计人员来说，这些模式可能更有用些。对于coder来说只要会语言就够了。

>我可以把对象的许多方法都写成静态方法当做工具来使用。但是却不知道>什么时候才应该这样做。

当一些东西将被作为工具来用时，使用静态方法，或者你可以使用Util这样词语替代包括这些东西时，就可以了。

>又如假设一个逻辑段放到多个对象中都是合理>的，那怎么决定它应该是哪个对象的方法呢？

如果一个逻辑段可以放在多个对象中，那么它就可以单独组成一个对象，并成为这个对象的方法。

这些解决办法其实没有一本书或文章详细介绍，那么我怎么会这样处理？因为我非常研究学习设计模式后，觉得已经领会其精神实质：其实就两个字，封装和分派。

但是就这两个字的理解，没有设计模式的研究学习，以及实践的再锻炼，你不可能从骨子里面理解这四个字。

所以也象Iceant所说，学习模式后，以后心中可以没有模式了，因为模式的哪些表面东西已经从你心里流失，剩余的就是面向对象编程实践的精华和真谛，一生受用。

>这些模式可能更有用些。对于coder来说只要会语言就够了。

我想我上面的回贴正好也回复了这个问题。

上面回贴中关于逻辑段安排的考虑，应该算是coder吧，如果你们没有设计模式学习，你的code质量将非常差。

设计模式是code级别的，是code和系统架构设计的桥梁。对于具体coder来说，使用设计模式可以有助其它人更加了解你的编码，因为目前XP或RUP工程方法中，系统设计不可能详细到所有代码，需求变化也导致coder有很多设计工作要做。

而使用设计模式，无疑帮助你更快、更优雅、更巧妙地实现coding。

设计模式是coding级别掌握面向对象编程思想的真正必修课程。

过去，我们总是衡量一个程序员编制多少代码，代码越多，他好像越厉害，其实，这其中有工匠和设计师的区别，是否掌握设计模式是进行这种鉴别的真正试金石。

> 怎么这么多人讨论设计模式，很少人讨论面向对象编程实践
>
> 感觉中国人就坏在好高骛远上了，同意的举手！

程序员、需求分析员、系统设计员、项目组长、项目经理、部门经理、技术总监、公司老总；
很多人在说，很多人在谈，很多人在看，很多人在做，东西就一个，理解各不同。
理论、原理、方法、方式、架构、框架、模型、模式、规范、范例、形态、状态、管理、运营、运作、分析、设计、开发、运行、抽象、继承、覆盖、引用、调用；
说了很多，谈了很多，看了很多，做了很多，东西就一个，应用各不同。

公司老总要负责公司整体的管理、运营、发展、......
技术总监要负责公司技术的管理、发展、跟踪、......
部门经理要负责软件人员的管理、培训、分派、......
项目经理要负责软件项目的管理、控制、跟踪、......
项目组长要负责子项目的管理、开发、协调、......
系统设计员要负责项目的分析、设计、评估、......
需求分析员要负责需求的调研、交流、协调、......
程序员要负责程序的编码、调试、分发、......

不同的人做不同的工作、不同的人做一样的工作、同样的人做不同的工作，同样的人做同样的工作 ；
谁又能说，设计模式就只是设计模式呢，
设计员可以把设计模式用在代码段之间、类与类之间，
程序员为什么就不能把设计模式用在代码段内、行与行之间呢；
项目经理为什么就不能把设计模式用在项目的系统架构上、项目与项目之间呢；

部门经理为什么不能把FACTORY模式应用在技术人员的培训上呢？
人力资源经理为什么不能把STATE模式应用在员工的管理上呢？
公司老总为什么不能把BUIDLER模式应用到公司组织架构上呢？

软件专家说设计模式是优化开发的方式；
经济学家说设计模式是降低成本的方式；
管理学家说设计模式是减少内耗的方式；
系统学家说设计模式是协调运行的方式；
东西就一个，理解的不一样；应用的不一样；各种认知都有自己的体系坐标，其间相互有交叉有重叠还甚至有差异；
关键一点是你能不能建立自己的完备的软件知识体系和学习方式；能不能把各说纷纭，你认为有用的有价值的东西纳入或规范到自己的软件知识范畴的不同层面中。
形成自己的东西。从系统论的角度上来说，这本身就是一个降低系统耦合的过程。
例如：我们可以把软件认知体系分为：代码关键字->代码行内->代码行间->代码段内->代码段间->代码类（模块）内->代码类（模块）间->
程序内->程序间->项目内->项目间->部门内->部门间->公司内->公司间->.......;每一个层面都有自己的理论、方法、模式、模型、架构、规范等等；自然会有共通之处。

需要设计模式吗，不需要吗，需要吗......

ooa后的ood，也就是把现实世界的模型转换成计算机能处理的模型，是比较困难的，而在采用面向对象方法中，设计模式提供了一种很好的解决方案，有助于你把通过ooa分析的模型转换到计算机中去。这又怎么会是好高骛远呢？

> 例如我可以把对象的许多方法都写成静态方法当做工具来使用。但是却不知道什么时候才应该这样做。

大约在一年之前,我也存在类似的困惑。当时我把所有的工具方法都写成静态的。
现在我会判断某个方法是否确定不会改变，如果是这样，我才把它写成静态的。
比如我有一个方法getFirstDayOfWeek得到本周的第一天，那么无论用在什么地方它都不会变化，所以它应该是一个静态的方法。
又例如一年以前我写了一个将数据导出为execl的工具类。该类只有一个静态方法，长度超过100行。后来我对其进行重构，将长方法分解为多个小的方法。然后将在多个方法间传递的变量提取出来，变为类的实例变量(instance variable)，再将这些小方法改为非静态的。现在，我只需要改写(override)其中的小方法，就可以方便的定制输出为execl时的属性，比如字体、格式等。
也就是说，如果工具方法有可能需要修改时，不要使用静态方法。如果你无法判断一个方法子类是否需要改写它，可以申明为final，这样将来修改时也方便。面向对象的核心就是多态，所以尽量少用静态方法。

> 现在我在发现我更需要的是面向对象编程的一些基本原则和指

确实这样.我认为对于程序员来说，最重要的是面向对象编程的一些基本原则，然后是编程方法，最后才是设计模式。
面向对象的基本原则比如：封装性，组合优先于继承，接口继承优先于实现继承。
编程方法比如：重构和测试驱动开发。
其实，如果真正实践了测试驱动开发，那么得到代码肯定符合封装性和模块化。因为可测试性迫使你必须做到模块化。我认为重构在软件开发中是最重要的，没有人能一开始就写出完美的代码，肯定需要不断的改进。通过去掉重复的代码和坏味道，我们就可以得到一个干净、简洁而又优美的实现。
设计模式对我来说，一是设计的时候可作为参考，一是为重构提供一个参考方向。当然，对于一些简单常用的设计模式，比如工厂方法、单例等，还是需要熟练掌握的。

那我就CHALLENGE一下，有没有自认为设计模式已经研究得不错的
随便设计一个对象，把代码放上来让大家点评一下如何？ 比如设计和实现一个电梯对象

我想这样大家可以有更直观的认识，不要纸上谈兵。这样学习我觉得可以比较有效。

好，您已经是教授级的人了！您也写一本书吧，我一定买！