读书人

大家来讨论下各种设计模式解决办法

发布时间: 2012-02-06 15:52:45 作者: rapoo

大家来讨论下各种设计模式
给大家提个问题,在你自己的开发过程中使用最多的模式是什么,并简要的举例说明下,以供大家学习!希望大家不吝赐教!

[解决办法]
据说有3000多个设计模式。
[解决办法]
状态模式:
其实了解设计模式之初,我是不太看好这个模式的,但在应用中我发现它的确是最常用的一个。我个人比较常用的方式如下:
条件一:当一个对象的逻辑慢慢复杂起来之后,就需要通过重构对其进行简化,这个时候一个很常用的手段就是把一组很内聚的属性抽取出来作为一个新的类对象;
条件二:很多时候这类属性都具有状态特性,比如游戏设计玩家会有各种不同类型的动作,像站立、行走、持续性动作、多人组合动作等等;玩家的不同成长阶段的针对同一指令的行为也会不一样------这样就构成了一个玩家属性的类族,是为状态模式
[解决办法]
2楼的所讲 令我有所思

个人常用的 应该是对象工厂...
可能是深受com的影响
[解决办法]
理解开发模式的前提是要理解面向对象设计原则(OO原则)。
最经典的开发模式有23个,从里面都可以找到OO原则的影子。
[解决办法]
面向对象设计估计在实践出真知啊。。。
[解决办法]
Composite模式:
在面向对象的系统中,经常会遇到一类具有“容器”特征的对象,即它们在充当对象的同时,又是其他对象的容器。这时候可以考虑用Composite模式。比如:在操作系统中,文件的概念很广泛,其中文件可以是普通文件,也可以是目录(在Unix中,设备也是文件),目录中可以存放文件。
Composite模式实际上隐含实现了递归算法。



[解决办法]
设计模式用得不多。
感觉蛮多还挺好用的。

桥接模式,用来跨平台移植还蛮还好用的。
[解决办法]
Chain of Responsibility(COR)也非常有意思:
在软件系统中,一个请求可能被多个对象处理,但是每个请求在运行时只能有一个接收者,如果显示指定,将必不可少地带来请求发送者与接收者的紧密耦合。COR(Chain of Responsibility)设计模式可以使请求的发送者不需要指定具体的接收者,让请求的接收者自己在运行时决定来处理请求,从而使两者解耦。

使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递请求,知道有一个对象处理它为止。

[解决办法]

探讨
设计模式用得不多。
感觉蛮多还挺好用的。

桥接模式,用来跨平台移植还蛮还好用的。

[解决办法]
有限状态机!
[解决办法]
最多,最常用的就俩:单例模式,还有对象工厂
[解决办法]
Singlton,Factory,几种用的比较多
[解决办法]
工厂模式应该肯定是最多的 -_-
[解决办法]
个人感觉设计模式只是一个称号,其实在实际编程中我们用到了很多潜在的设计模式
比如String的使用以及模板的使用
[解决办法]
Sigleton abstract Factory 常用。
[解决办法]
我们boss正在提倡一个“极限编程”,还没弄清楚。据说很有用。
[解决办法]
用的最多是工厂模式、桥模式、单件模式...
[解决办法]
有限状态机
[解决办法]
工厂模式
[解决办法]
观察者模式。
做MVC的几乎都用观察者。
[解决办法]
观察者模式/工厂模式/单实例模式
[解决办法]
哥们,你能举个例子说明一下吗?
[解决办法]
探讨
观察者模式。
做MVC的几乎都用观察者。

[解决办法]


前段时间买了本大话设计模式!挺不错的。
设计模式牛!
[解决办法]
很好,不错
[解决办法]
10万行代码以 下 经验没有 ,个人觉得没有必须去追求 设计模式。。
[解决办法]
说都会说,写个demo也都会,真正应用的时候就麻了
[解决办法]
知道但还用不来啊!!!
[解决办法]
工厂
[解决办法]
观察者模式
[解决办法]
无所谓设计模式,反正大家都喜欢跟着老外屁股后面走···
我个人觉得OO化很适合市场化的运作模式,经验尚浅没能理解的很深入。····各位别喷我。
除了MVC用过外,其他的都没基础过。
[解决办法]

1. 状态模式:绘图的时候所用的鼠标工具类。
2。策略模式:用于文件夹扫描。统一的扫描过程,施加不同的算法操作(记录文件信息,删除。。。)
3。MVC:程序框架
4. 模板模式:界面元素的绘制过程:背景绘制,前景绘制
5。单件模式:资源管理类
。。。

[解决办法]
项目中比较常用的模式有 工厂模式,单例模式,和观察着模式,特别是观察者模式,
几个模块交互时用的比较多。
[解决办法]
主要用到的有:工厂模式、单例模式、装饰器模式、观察者模式、组合模式、适配器模式、MVC模式、前端控制器模式(Web领域的模式)
[解决办法]
任务链...掩面飘过~~~
[解决办法]

探讨
据说有3000多个设计模式。

[解决办法]
世界本没有模式,改的人多了,便有了模式~~
[解决办法]
我也受com的影响,比较喜欢用工厂模式,单件模式。

此外还有策略模式(极其喜欢用模板写策略模式,每次项目都要专门写)。

此外,诸如什么代理模式,观察者模式也时不时用一下。
[解决办法]
在我经历过的开发里,经常用到而且对架构影响最大的应该是观察者模式了。它的变体相当多,有直接派生接口的,也有组合、聚合的。不过往往写着写着发现自己的代码里已经无处不模式了~感觉模式本身只是一些实践,而它所依赖的OO设计原则更为重要。也就是那些“针对接口编程,不要针对实现编程”、“最少知识原则”等等,不要盲目的应用模式。
[解决办法]
探讨
说都会说,写个demo也都会,真正应用的时候就麻了

[解决办法]
不要为模式走火入魔
[解决办法]
现在我这里Observer模式用的比较多
[解决办法]
偶常用两种:

1. Singleton

C# code
/* *  * 通常我们可以让一个全局变量使得一个对象被访问, 但它不能防止你实例化多个对象. 一个最好的办法就是:让类自身负责保存它的 * 唯一实例. 这个类可以保证没有其他实例可以被创建, 并且它可以提供一个访问该实例的方法. *  * 单例模式因为Singleton类封闭它的唯一实例, 这样它可以以严格地控制客户怎样访问它以及何时访问它. 简单地说就是对唯一实例 * 的受控访问. *  */using System;using System.Collections.Generic;class SingletonModel{    public static void Main()    {        Singleton s1 = Singleton.GetInstance();        Singleton s2 = Singleton.GetInstance();        if (s1 == s2)        {            Console.WriteLine("两个对象是相同的实例.");        }                Console.ReadKey();    }}class Singleton{    private static Singleton instance;    private Singleton()    {    }    public static Singleton GetInstance()       //此方法是获得本类实例的唯一全局访问点    {        if (instance == null)                   //若实例不存在, 则New一个新实例, 否则返回已有的实例        {            instance = new Singleton();        }        return instance;    }}
------解决方案--------------------


最多的工厂+反射、单例、装饰器
别的有时在不知不觉中也有用到,
设计模式重在思想,而不是为了设计而设计
[解决办法]
工厂
单例
观察者(这个太棒了 用起来很爽)
装饰者
命令
任务链
桥接

只有上面用过其他的一概不知
[解决办法]

探讨
理解开发模式的前提是要理解面向对象设计原则(OO原则)。
最经典的开发模式有23个,从里面都可以找到OO原则的影子。

读书人网 >C++

热点推荐