论坛首页 Java企业应用论坛

学习设计模式的一些常见问题

浏览 18462 次
精华帖 (0) :: 良好帖 (4) :: 新手帖 (0) :: 隐藏帖 (1)
作者 正文
   发表时间:2011-09-03  
设计模式可以学习,但是不可以背诵。
0 请登录后投票
   发表时间:2011-09-03  
大家可能需要好好回顾一下什么是模式? 简单的说模式不就是一种方案吗, 能很好解决特定领域的反复出现的特定问题. 怎样应用模式, 先要搞清问题(领域模型), 能后按问题去查模式字典里有没有配匹的模式适合解决这问题 如果没有找到, 恭喜你, 你发现了新大陆了, 可能可以创建你自己的模式了.只能是可能, 实际上这时候通常也只叫方法不能叫模式. 注意模式定义中的"反复出现"很重要.

我理解是模型是解决"What"的问题, 而模式是解决这个"What"的"How". GoF只不过是定义了个木板把过去的经验总结得象字典, 让我们方便查找. 这已经是公德无量了.

所以模型和模式不存在谁重不中要的问题, 这只是思考的一个逻辑顺序而已. 同常我们回觉得模式很重要, 那是我门在开发应用时就是那么些个问题几乎相似, GoF的总结的那23个模式都覆盖了. 所以LZ觉得模型重要.

顺便说一下, 我觉得模式和模型和OO没什么关系, 用OO来描述模式和模型比较方便吧. 例如, 传统的WIN32的事件驱动方法(实际上是WIN32的一种模式), 为了创建一个Window, 我们必须给这个Window提供一个窗口涵数, 这个窗口涵数的实现就是一个大的循环. 它至少应用了命令(Command), 解释(Interpreter), Adapter(delegate)模式, 不是吗? 它解释每个消息(WM_xxx), 执行代码(动作), 不能解释的消息(WM_xxx), 转给窗口缺省涵数(delegating adapter). WIN32的send接口不就实现Chain of Responsibility吗?

GoF用OO描述模式, 这也成了一种模式了啊!

0 请登录后投票
   发表时间:2011-09-03  
jok 写道

........
所以模型和模式不存在谁重不中要的问题, 这只是思考的一个逻辑顺序而已. 同常我们回觉得模式很重要, 那是我门在开发应用时就是那么些个问题几乎相似, GoF的总结的那23个模式都覆盖了. 所以LZ觉得模型重要.
......

漏了. 所以模型和模式不存在谁重不中要的问题, 这只是思考的一个逻辑顺序而已. 同常我们会觉得模式很重要, 那是我门在开发应用时就是那么些个问题几乎相似, GoF的总结的那23个模式都覆盖了. 所以LZ觉得模型重要, 可能GoF总结的模式覆盖了几乎所有的问题, 我们只要集中精力搞模型. 谁能把模按领域型总结总结??
0 请登录后投票
   发表时间:2011-09-03  
作为软件工作者,为客户提供符合要求的软件产品是第一要素,是商业软件的纯粹目的.世人被金钱蒙蔽了眼睛,往往忽略了最重要的素养.软件本身模式设计的合理,代码的精炼程度,科学的复用设计,会增强代码的可读性以及降低后期维护成本.这是编程人员的基本职业素养.没有这种素养,在软件编程领域,就是所谓的"混",至少在技术领域,续航力弱. 国内的软件人才,具有开拓技术能力的人寥寥无几,很大数量的人都是"堆代码",本身就让国内业界无颜,如果代码都"堆"不好,岂不让世人笑!
望同行的同事,还是能以质量为内心第一,以学习创造为内心第一."客户第一"的话,我们只说给客户听,而不是说给同行听.

1 请登录后投票
   发表时间:2011-09-03  
开发中使用设计模式,并不是为了故弄玄虚显摆自己,也不是故意把简单的问题复杂化,而是为了达到如下两个目的:
1、为了代码的逻辑清晰和分工明确,方便后来人维护,方便以后扩展功能;
2、为了使用一个大家都看得懂且公认的步骤来表述你的目的,比如:别人看到你写得几个Command相关类,就知道你是使用命令模式来达到动作参数化,操作可撤销化的目的。
0 请登录后投票
   发表时间:2011-09-03   最后修改:2011-09-03
什么时候在开发中用设计模式,什么时候不用?这个标准比较难界定。
一般的软件公司的程序员,分为两类:
A、流水线程序员;
B、软件架构师。
软件架构师负责软件整体架构设计、底层技术包装、结合业务实际搭建项目框架、多数也会参与或主导设计数据模型。

作为架构师,应该尽量使用设计模型,以使得软件框架规整、有条理、易扩展、低耦合,使得软件框架留给流水线程序员看到的东西尽量地简单。

比如流水线程序员继承一个抽象类,在类中实现几个抽象方法,就可以运行得到一个漂亮的Swing JPanel面板,点击面板上的JButton按钮,自动调用流水线程序员实现的方法。

这些是需要软件架构师为流水线程序员提供外观尽可能简单的包装。
所以软件架构师需要使用设计模式,尽量不对流水线程序员暴露复杂的实现,只提供简单的填空部分。



而作为流水线程序员,就没有必要关心设计模式了,你安心地填空就是了,该在哪里写几行代码,就在哪里写那几行代码,不需要你变着花样去多创造几个类来绕弯子。
如果你觉得自己非要用一两个设计模式,绕几道弯才能达到目的,那只能说明两个问题:
1、你的软件架构师是个庸才或者懒惰的人,让你做得面太大了;
2、你已经超越了你的软件架构师,你可以向老板提议给自己加薪了。
0 请登录后投票
   发表时间:2011-09-03  
其实我个人认为,有时候会陷入为了模式而模式的一种怪圈,XX模式好,所以我一定要用。

设计模式我觉得应该是把正确的模式用在正确的地方,才能体现出优势来,但是能做到这一点并不是简单的事情。
0 请登录后投票
   发表时间:2011-09-04  
wangyu1221 写道
其实我个人认为,有时候会陷入为了模式而模式的一种怪圈,XX模式好,所以我一定要用。

设计模式我觉得应该是把正确的模式用在正确的地方,才能体现出优势来,但是能做到这一点并不是简单的事情。


恩,很到位,书里有讲,可仔细参阅第一章和最后几章,这本书借助模式讲OO,因为面向对象的设计模式是OO的最佳实践。
0 请登录后投票
   发表时间:2011-09-04  
george_space 写道
什么时候在开发中用设计模式,什么时候不用?这个标准比较难界定。
一般的软件公司的程序员,分为两类:
A、流水线程序员;
B、软件架构师。
软件架构师负责软件整体架构设计、底层技术包装、结合业务实际搭建项目框架、多数也会参与或主导设计数据模型。

作为架构师,应该尽量使用设计模型,以使得软件框架规整、有条理、易扩展、低耦合,使得软件框架留给流水线程序员看到的东西尽量地简单。

比如流水线程序员继承一个抽象类,在类中实现几个抽象方法,就可以运行得到一个漂亮的Swing JPanel面板,点击面板上的JButton按钮,自动调用流水线程序员实现的方法。

这些是需要软件架构师为流水线程序员提供外观尽可能简单的包装。
所以软件架构师需要使用设计模式,尽量不对流水线程序员暴露复杂的实现,只提供简单的填空部分。



而作为流水线程序员,就没有必要关心设计模式了,你安心地填空就是了,该在哪里写几行代码,就在哪里写那几行代码,不需要你变着花样去多创造几个类来绕弯子。
如果你觉得自己非要用一两个设计模式,绕几道弯才能达到目的,那只能说明两个问题:
1、你的软件架构师是个庸才或者懒惰的人,让你做得面太大了;
2、你已经超越了你的软件架构师,你可以向老板提议给自己加薪了。

使用OO编程和职位没有太多直接的关系,只要你使用OO语言编程,就会用到,只是很多人是使用OO语言编写过程式代码。
0 请登录后投票
   发表时间:2011-09-04  
feng2356 写道
作为软件工作者,为客户提供符合要求的软件产品是第一要素,是商业软件的纯粹目的.世人被金钱蒙蔽了眼睛,往往忽略了最重要的素养.软件本身模式设计的合理,代码的精炼程度,科学的复用设计,会增强代码的可读性以及降低后期维护成本.这是编程人员的基本职业素养.没有这种素养,在软件编程领域,就是所谓的"混",至少在技术领域,续航力弱. 国内的软件人才,具有开拓技术能力的人寥寥无几,很大数量的人都是"堆代码",本身就让国内业界无颜,如果代码都"堆"不好,岂不让世人笑!
望同行的同事,还是能以质量为内心第一,以学习创造为内心第一."客户第一"的话,我们只说给客户听,而不是说给同行听.


是的,什么能够支撑你做到客户第一,就是优雅的软件,可扩展性,可伸缩性,以及恰当的简单,做一个款软件,是一个系统工程,不是光写代码了事,怎样理解需求和改进需求这些也非常只要,我的书籍主要涉及了编程,对于复杂的业务,本人喜欢使用DDD开发,效率非常高,给用户可以带来意想不到的满意。
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics