[专题讨论]设计模式及应用

pillow

静态方法和singleton模式没有可比性，是两个层次的东西，比如我有一个Mapper的类，需要缓存一系列树状结构的Objects，同时提供获取Object的find方法，这个用singleton就很容易实现，但是静态方法是没办法去实现这样的功能的

单例和多例的功能的确是在一个范围内（比如一个JVM）只创建一个（或有多个）实例，关键是创建这样的实例干什么，只有明白了这个，才能真正学会使用Singleton

木南楠

１.请设想并实现一个实际的、不少于4层的Composite模式，要考虑到组件增加、删除、
缓冲存储、安全和透明等5个特性，并对这5个方面的特性做文字说明。
       

３. 请实现下列功能（自然语言描述）：

模拟两个战车团A和战车团B，每个战车团中都包含四种战车：
        重型坦克、轻型坦克、装甲战车和自行火炮；
A团处于警戒状态静止不动，
B团向A团靠拢，A团的火力比B团的火力强。
当B团进入A团的火力范围的时候，A团自动开炮射击；
当B团判定A团进入己方火力范围的时候，也自动开炮射击；
当A团消灭B团的时候，A团停止射击。
用线程技术结合享元模式完成设计。

有会的吗？谢谢了！！！

木南楠

大家帮帮忙吧，如果方便的话可以私聊，有愿意的吗？？我在线等～～～～～～～～～！！！

fuchunxia

在java模式中讲了23中模式，这两个都是创建模式的。
区别比较的明显的，abstract factory是factory在功能上的进一步扩展的

我一直不明白这些模式有什么用？设计程序时就是凭感觉和经验，有了这些模式后反而限制了人们的创新。
其实所有模式不过都是抽象的框架，让我们通过接口来连接具体实现。这些抽象框架怎么会这么简单的几十个模式所能包括的。

yining

首先，设计模式并不止23个，而是有上千个。其次，设计模式并不是为了限制人们的创新，就在今天，设计模式也是在不断的被人发现的。举一个简单的例子，电子电路中有一种基本的器件叫做集成运放。这种器件是由三极管加上其他的器件做成的。基本上，利用集成运放可以做成90%以上的其他任何电子产品，那么，还有什么必要仍然从三极管，电阻电容开始设计一个电路呢？为什么不能够从集成运放开始，更快，更有效的设计电子电路呢？当然，直接使用集成运放，不意味着不理解集成运放背后的概念。

clkrst

设计模式还是非常有用的。大道理前面说得很多了

如果有人水平很高，大可以不去学这些设计模式，直接在程序中自己发现，自己使用，当然好了。就好像一个人做数学题，完全可以自己把需要的定理全都证出来，没必要学习那么多定理嘛。不过显然，这样的人是难得的天才啊。

pillow

I hava recently read some articles and reference about dynamic Proxy
and Aop, Aop is realy a excellent architecture, the base widgets and
common components are separated from the business logic clearly. I
think that the all  common components would be implemented by the J2EE
and DotNet, what would be left for us, for the engineers? only
business logic, there is no architecture, no senior engineer but coder
and business consultant. It is so sad.

R&D, if you can't do the research job, then no development for you, just coding.

Angel.John

Observer(观察者)模式是比较常用的一个模式.
如果系统的对象值或属性有变化,系统能自动通知各相关对象，触发相关的更新或操作。

xipipku

设计模式还是非常有用的，尤其是在做概要设计和详细设计时，作为一个系统设计人员，它必须要考虑到系统的扩展行，兼容性的问题，尤其考虑一个产品要到各地去客户化的时候，设计模式显的尤为重要，下面一段话是别人总结的一些设计模式的好处：
1. 最大化的重用：这个重用包括组件重用 和设计模式使用等多个方面。
比如，我们项目中有用户注册和用户权限系统验证，这其实是个通用课题，每个项目只是有其内容和一些细微的差别，如果我们之前有这方面成功研发经验，可以直接重用，如果没有，那么我们就要进行这个子项目的研发，在研发过程中，不能仅仅看到这个项目的需求，也要以架构的概念去完成这个可以称为组件的子项目。
2. 尽可能的简单明了：我们解决问题的总方向是将复杂问题简单化，其实这也是中间件或多层体系技术的根本目标。但是在具体实施设计过程中，我们可能会将简单问题复杂化，特别是设计模式的运用上很容易范这个错误，因此如何尽可能的做到设计的简单明了是不容易的。
我认为落实到每个类的具体实现上要真正能体现系统事物的本质特征，因为事物的本质特征只有一个，你的代码越接近它，表示你的设计就是简单明了，越简单明了，你的系统就越可靠。更多情况是，一个类并不能反应事物本质，需要多个类的组合协调，那么能够正确使用合适的设计模式就称为重中之重。
我们看一个具备好的架构设计的系统代码时，基本看到的都是设计模式，宠物店(pet store)就是这样的例子。或者可以这样说，一个好的架构设计基本是由简单明了的多个设计模式完成的。
3. 最灵活的拓展性：架构设计要具备灵活性 拓展性，这样，用户可以在你的架构上进行二次开发或更加具体的开发。