討論strategy和decorator的不同和相同之處?

[PageYi]

我個人認為:這兩種模式都是多態的一種實現方式﹐strategy則用在當具體實現互不相同時﹐decorator則是用在具體實現有一些相同﹐但需要增加一些功能時。
本人菜鳥一個﹐希望大師指點

[will52000]

strategy目的是改变接口来适应变化,可以用继承和作为成员来实现.decorator通常是用来实现功能的
扩展,接口上仍能保持一至.

[will52000]

错了,第一个我是想说adapter

[will52000]

strategy目的是功能的选择,并把功能封装起来.decorator目的是功能的扩展.

[Arhero]

--：〉支持小阿！

[shipp]

strategy:各种算法的替换;
decorator:对象功能的扩展.

[weimenren]

The Strategy Pattern: Key Features

Intent:
Allows you to use different business rules or algorithms depending upon the context in which they occur.
Problem:
The selection of an algorithm that needs to be applied depends upon the client making the request or the data being acted upon. If you simply have a rule in place that does not change, you do not need a Strategy pattern.
Solution:
Separates the selection of algorithm from the implementation of the algorithm. Allows for the selection to be made based upon context.
Participants and Collaborators:
1. The strategy specifies how the different algorithms are used.
2. The concreteStrategies implement these different algorithms.
3. The Context uses the specific ConcreteStrategy with a reference of type Strategy. The strategy and Context interact to implement the chosen algorithm (sometimes the strategy must query the Context). The Context forwards requests from its Client to the Strategy.
Consequences :
1. The Strategy pattern defines a family of algorithms.
2. Switches and/or conditionals can be eliminated.
3. You must invoke all algorithms in the same way (they must all have the same interface). The interaction between the ConcreteStrategies and the Context may require the addition of getstate type methods to the Context.
Implementation:
Have the class that uses the algorithm (the Context) contain an abstract class (the stragegy) that has an abstract method specifying how to call the algorithm. Each derived class implements the algorithm as needed. Note: this method wouldn't be abstract if you wanted to have some default behavior.
Note:
In the prototypical Strategy pattern, the responsibility for selecting the particular implementation to use is done by the Client object and is given to the context of the Strategy pattern.

[weimenren]

The Decorator Pattern: Key Features
Intent:
Attach additional responsibilities to an object dynamically.
Problem:
The object that you want to use does the basic functions you require. However, you may need to add some additional functionality to the object, occurring before or after the object's base functionality. Note that the Java foundation classes use the Decorator pattern extensively for I/O handling.
Solution:
Allows for extending the functionality of an object without resorting to subclassing.
Participants and Collaborators:
The ConcreteComponent is the class having function added to it by the Decorators. Sometimes classes derived from ConcreteComponent are used to provide the core functionality, in which case Concrete-Component is no longer concrete, but rather abstract. The Component defines the interface for all of these classes to use.
Consequences:
Functionality that is to be added resides in small objects. The advantage is the ability to dynamically add this function before or after the functionality in the ConcreteComponent. Note: While a decorator may add its functionality before or after that which it decorates, the chain of instantiation always ends with the ConcreteComponent.
Implementation:
Create an abstract class that represents both the original class and the new functions to be added to the class. In the decorators, place the new function calls before or after the trailing calls to get the correct order.

[weimenren]

Strategy 基于算法的互换

而

Decorator 基于给对象增加功能，其比生成子类灵活

[GFDVAn]

感觉decorator象滚雪球。。。 滚一圈大一点 功能就多一点

[PageYi]

我認為Decorator和Strategy應該同為Behavioral,為什麼Gang of four要把Decorator放在Stuctural里?

[PageYi]

weimenren(宁静以致远，淡泊以明志),你這是<design pattern explained>上的吧
能不能再比較具體一點

[weimenren]

Strategy是对象行为类模式，焦点在对象的行为，其目的就是通过一种途径显现行为的变化。 其主要用于封装行为变化，在Strategy中，这里的行为就是一系列的算法，也就是需要封装这一系列的算法。在这里一般将算法(ConcreteStrategy)抽出来单独的定义一个类。为了达到对接口编程的目的，将所有的算法的类的共同点抽象出一个接口（Strategy）,这样在Context就不用去关心使用什么算法，它只需要知道使用Strategy就好了。

Decorator是结构模式，焦点在对象的结构，其涉及到如何组合类以及如何让对象获得更大的结构。结构行模式不是对接口和实现进行组合，而是描述了如何对一些对象进行组合。 从而实现新功能的一些方法。因为可以在运行时刻改变对象的组合关系，所以对对象组合方式有更大的灵活性。 在Decorator模式中涉及到如何动态的给对象添加功能。其采用递归方式组合对象，从而允许你添加任意多的功能。

[weimenren]

在Decorator中，仅从外部改变Component，而Component无需对他的装饰有任何了解，也就是说这些装饰对于该 Component是透明的

而在Strategy中，component本身需要知道可能进行哪些补充，因此他必须引用并维护相应的策略

基于Strategy的方法可能需要修改component以适应新的补充

用一个装饰你可以改变对象的外表，而Strategy可以使你改变对象的内核

[PageYi]

weimenren(宁静以致远，淡泊以明志) ,你一直再說他們的不同之處,您覺得這兩種模式有相同的地方嗎?

[weimenren]

1、楼主应该仔细看两种模式的结构

就Strategy来说，理解为多态的一种实现方式尚可，context 本身包含一个算法（已抽象出为一个单独的类或接口Strategy）的接口，具体使用哪个算法（ConcreteStrategy皆继承了Strategy），而算法基于用户的选择。 Strategy - >ConcreteStrategy采用了多态的实现方法（行为的多态），所以GoF放到行为模式中，在最终的实现中，也就Context通过Strategy找到了它所需的操作的一个算法。

而就Decorator来说， Decorator继承了Component，他同时可能还拥有一个Component，这样在同一个操作中，你可以在Decorator中任意时刻添加操作。　在最终的实现中，Component通过Decorator，灵活的添加了一些其他的功能。　这个模式的主要意图是避免继承带来的类爆炸。

Decorator - > ConcreteDecorator 中是实现了多态，但其中更主要的一点用途还在于可以创建decorator链

Decorator1 -> Decorator2 -> Decorator3 -> ConcreteComponent

２、你若非要说相同点
不外乎在Decorator -> ConcreteDecorator　以及 Strategy -> ConcreteStrategy 使用了多态

３、如何学习设计模式
在设计模式的学习中，我想我们更应该注意的是理解模式的意图，目的，而后具体去看他如何实现，了解为什么会需要这种模式，什么时间适合使用这个模式，模式的结构，模式的参与者，各个组件间有如何的相互关系，相互之间如何协作。

在设计模式的图例中到处是多态的实现，我们不能因为模式的某部分使用了多态就以为仅仅多态。

学习设计模式需要定期总结，在学完一个模式后需要自己具体的写几个简单的例子，最少需要理解看到的例子吧。

[launch401]

赞成weimenren这句话：“在设计模式的学习中，我想我们更应该注意的是理解模式的意图，目的”。

说一说我的理解：

decorator的动机是为动态任意扩展对象的功能。而strategy的动机是为了动态改变对象的功能。

关于decorator和strategy的比较GOF的书中在讲decorator时讲的很详细了:
“decorator改变对象外壳而strategy改变对象内核”，

两者的目的都是为了改变对象的功能。当对象比较庞大时用decorator代价比较大，可以在这时候用strategy。实际上用strategy来改变对象的功能可以达到与decorator完全相同的效果（仅对对象功能而言），因为strategy也可以嵌套嘛，大家可以看看GOF中的decorator的实现一节中第四小标题中的那两副图。

我觉得decorator和strategy和最大不同是decorator对client是透明的，client可以完全不知道decorator的存在；而对strategy来说，client必须知道有哪些strategy可用，因为strategy的扩充对client是不透明的