首页 > 代码库 > 从变化逻辑的封装谈设计模式

从变化逻辑的封装谈设计模式

2024-07-12 18:06:56   219人阅读

通常来说，对于某个满足了我们大部分需要的类，可以创建一个它的子类，并只改变其中我们不期望的部分(需要变化部分)。只是继承一个类，就可以重用该类的代码，这是一件多美好的事情啊！不过，像大多数美好的事情一样，过度使用往往会变得不美好。根据可替换原则（LSP）, public 继承具有概念上的现实意义，它代表的是一种is-a关系。使用继承之前一定要问问是否真的属于is-a的关系，否则继承非常容易被过度使用。基于此，建议优选使用对象组合（object composition）而不是类继承（class inheritance）。Strategy模式是将需要变化的逻辑封装在外部，然后通过组合方式把这部分易变化的逻辑传递给主题类。Strategy有各种变体，咱们来一一探讨：

方法一：如果需要变化的逻辑可以包装到一个函数中，可以藉由Function Pointers实现Strategy模式。（例子引自<>）

class GameCharacter;
int defaultHealthCalc(const GameCharacter& gc);
class GameCharacter {
public:
	typedef int (*HealthCalcFunc) (const GameCharacter&);
	explicit GameCharacter(HealthCalcFunc hcf = defaultHealthCalc):healthFunc(hcf){}
	int healthValue() const
	{ return healthFunc(*this);}
	//...
private:
	HealthCalcFunc healthFunc;
};

这个做法是Stategy设计模式的简单应用。和virtual继承的做法比较，可以绑定不同的函数甚至提供了运行期绑定不同函数指针的可能。弊端是无法访问类对象的non-public成分。（如果有此需求，可能要考虑friend函数或者private继承的方式了，不在此讨论范围）

方法二：藉由函数对象完成Strategy模式。

使用tr1::function的对象，可持有任何可调用物（函数指针、函数对象或成员函数指针），只要其签名式兼容于需求端。本质与方法一相同。关键在于函数对象的使用上。

方法三：经典Strategy模式：把需要变化的逻辑做成一个分离开来的继承体系中的virtual成员函数。


标准的Strategy模式更加容易辨识和交流。这个方法的吸引力在于更加纯粹的面向对象设计（考虑一下非c++程序员的感受，以下面向对象相关设计转为更加面向对象的C#语言来表达。）。而且，如果变化的逻辑单元多于一个，可以做成多个不同的virtual方法。如果要将一个新的健康算法策略纳入应用，只要为HealthCalcFunc继承体系添加一个derivedclass即可。

继续我们的探讨，如果HealthCalcFunc的逻辑不仅要考虑到算法本身的不同，还要考虑计算对象（GameCharacter）的不同，那要怎么办呢？

变化如下：


class EvilBadGuy:public GameCharacter {
public:
	//...
	override int healthValue() const
	{healthCalcObj.calcHealthValue(this);}
private:
	HealthCalcFunc healthCalcObj;
};

这涉及到两个多态分发。第一个分发是healthValue函数。该分发辨别出所调用的healthValue方法所属对象的类型。第二个分发是calcHealthValue方法，它辨别出要执行的特定函数。这两个分发共同实现了让不同的子类实例调用不同的calcHealthValue函数的目的。

等等， HealthCalcFuncclass仅仅提供计算的逻辑，其实我们并一定非要在GameCharacter中保留它的实例状态。仅仅在需要的时候传入对象就行了。去掉聚合的data member, healthValue函数接口变为：

int healthValue(HealthCalcFunc) const
这样一来聚合关系就变成了依赖关系。如果我们再把类和函数接口的名字改变一下，完整的UML图应该如下所示：


啊，跑题了!这不是visitor模式吗？

上边的UML图确实就是一个visitor模式的类型图。：-）管它的，接着往下进行我们的故事吧。虽然用这一模式能解决我们的问题。想想看，它有没有什么问题，还有没有改进的空间呢？

注意！访问者层次结构的基类中对于被访问层次结构中的每个派生类都有一个对应函数。因此，就有一个依赖环把所有的被访问派生类绑定在一起。这样有什么问题呢？

这样，就很难实现对访问者结构的增量编译，并且很难向被访问层次结构中增加新的派生类。如果被访问层次结构非常不稳定，经常需要创建许多新的派生类，那么每当向被访问层次结构中增加一个新的派生类时，就必须要更改并且重新编译Visitor基类以及它的所有派生类。在C++中，情况更糟，每当增加任何一个新的派生类时，整个被访问层次结构就必须要被重新编译、重新部署。

问题的关键就在于解除这种如此强绑定的依赖环。让我们做出以下改动：



public override int accept (DegeneratedVisitor v)
{
    int value = http://www.mamicode.com/0;>
DegeneratedVisitor蜕变成一个空接口。对于被访问层次结构的每个派生类，都有一个对应的访问者接口。如此一来，依赖变成了稳定的接口依赖关系。即使发生扩展，变化将被集中在具体的visitor子类当中。被访问派生类中的accept函数把Visitor基类转型（cast）为适当的访问者接口。如果转型成功，该方法就调用相应的visit函数。
其实Visitor的派生类并不需要针对每一个被访问的派生类都实现visit函数，当且仅当它们需要发生交互的时候。给进化后的模式起一个新的名称：AcyclicVisitor模式。
这种方法解除了依赖环，并且更容易增加被访问的派生类以及进行增量编译。当然万事皆有缺点，它的缺点就是：模型更加复杂。由于转型需要花费大量的执行时间，当被访问层次结构的宽度和深度增加之后，会更加糟糕。
把话题带回到我们的出发点——对需要变化部分的逻辑进行封装和扩展。Strategy模式侧重于所施加策略的多样性，从而对其进行继承体系外的封装和扩展。Visitor更多的侧重与被访问主体的不同处理需求。如果存在有需要以不同方式进行处理的数据结构，就可以使用Visitor模式。二者都在不改变现有类层次结构的情况下实现了变化逻辑的扩展。其实还有更多的不改变类层次结构的情况下扩展功能的方式。例如Decorator模式，ExtensionObject模式。不同的模式，不同的方法具有不同的应用场景和侧重点。
最后我想强调的是:千万不要为了设计模式而模式，不要去死记硬背设计模式。开始面向对象设计之前，先让自己对继承，封装，多态的有更深刻理解。面向对象是思想！


联系
我们