より正確で明瞭な組み合わせを実現する設計

namespace A_Program
{
	struct DB
	{
		virtual void get_par(){ cout<<"DB get_par"<<endl; }
		virtual void set_par(){ cout<<"DB set_par"<<endl; }
	};

	struct Buf
	{
		virtual void get_par(){ cout<<"Buf get_par"<<endl; }
		virtual void set_par(){ cout<<"Buf set_par"<<endl; }
	};

	template< class _T >
	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"<<endl; }
		virtual void set_par(){ cout<<"DB set_par"<<endl; }
	};

	struct Buf: public Role
	{
		virtual void get_par(){ cout<<"Buf get_par"<<endl; }
		virtual void set_par(){ cout<<"Buf set_par"<<endl; }
	};
}

namespace C_Program
{
	struct IRole
	{
		virtual void get_par() = 0;
		virtual void set_par() = 0;
	};

	struct DB
	{
		virtual void get_par(){ cout<<"DB get_par"<<endl; }
		virtual void set_par(){ cout<<"DB set_par"<<endl; }
	};

	struct Buf
	{
		virtual void get_par(){ cout<<"Buf get_par"<<endl; }
		virtual void set_par(){ cout<<"Buf set_par"<<endl; }
	};

	template< class _T >
	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");
}

 
//初めて2つの実現案を見ても違いはありませんが、実際に//案Aはより正確で明瞭な設計を実現しました.そのベースクラスDBとBufはRoleに変更できない他の関連しないデータであり、権限の管理と分業がより厳格である.//一方、シナリオBは、関連するサブクラスがロールの他のデータを修正する権利を許可し、このような許可が設計の一部でない限り、このような許可は符号化エラーの可能性を増加させ、使用者の迷いを増加させ、設計目標から逸脱した実現に道を提供する.//効率的には、シナリオAは静的組合せであり、シナリオBは動的組合せである.シナリオAはより高速であるが、シナリオBは実行中に指定されたオブジェクトを動的に変更できるため、シナリオBに及ばない柔軟性を有する.しかし、本当に実行期間の需要があれば、シナリオAにベースクラスのカバーを1つ追加しても適応できます.//スキームCはAとBの利点を結合している.継承組合せをアプリケーション層に渡して決定し,クラスライブラリの肥大化を回避し(新しいクラスを増やし,それに応じて新しい組合せクラスを提供する必要はない),クラスライブラリの論理を精錬した.