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

最新推荐文章于 2023-12-27 21:00:10 发布

原创最新推荐文章于 2023-12-27 21:00:10 发布 · 626 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#struct #system #class

软件工程专栏收录该内容

141 篇文章

订阅专栏

本文详细解析了设计模式在编程领域的核心作用，通过对比不同实现方案，阐述了如何在保持代码清晰的同时，提高系统的灵活性和安全性。讨论了方案A、B、C在权限控制、效率和设计原则上的差异，并强调了选择合适的设计模式对于提升软件质量的重要性。

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

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