一种实现更精确明了组合的设计

namespace A_Program
{
	struct DB
	{
		virtual void get_par(){ cout<<"DB get_par"<
	struct Role: public _T
	{
		virtual void get_par(){ _T::get_par(); }
		virtual void set_par(){ _T::set_par(); }
	};
}

namespace B_Program
{
	struct Role
	{
		virtual void get_par() = 0;
		virtual void set_par() = 0;
	};

	struct DB: public Role
	{
		virtual void get_par(){ cout<<"DB get_par"<
	struct Role: public IRole, public _T
	{
		virtual void get_par(){ _T::get_par(); }
		virtual void set_par(){ _T::set_par(); }
	};
}

void main()
{
	A_Program::Role< A_Program::DB > testA;
	testA.set_par();

	B_Program::Role* p_testB = &(B_Program::DB());
	p_testB->set_par();

	C_Program::IRole* p_testC = &(C_Program::Role< C_Program::DB >());
	p_testC->set_par();
	system("pause");
}

 

//初看下两种实现方案都没什么区别， 但是事实上
//方案A实现了更精确明了的设计。其基类DB和Buf是不可能更改到Role的其它不相关数据，它对权限的把控和分工更严格。
//而方案B则充许了相关子类修改Role其它数据的权利， 除非这种充许是设计的一部份， 否则这种充许增加了编码出错的可能性和增加了使用者的迷惑,同时也给偏离设计目标的实现提供了途径。
//在效率上，方案A是静态组合，方案B是动态组合。　方案A速度更快， 但灵活性不如方案B，因为方案B可以在执行期动态改变所指对象。 但如果真有执行期的需求， 方案A加多一个基类套子也可适应。
//方案C结合了A和B的优点。把继承组合交由应用层去决定，从而避免类库的臃肿（增加新的类，不用相应提供新的组合类）， 精炼了类库的逻辑。