roc*_*ale 5 c++ oop inheritance hierarchy
好吧,我在考虑过去几天的设计决定,因为我仍然不能偏爱另一个,我想也许别人有个主意.
情况如下:我有几个不同的接口类抽象几个通信设备.由于这些设备的性质不同,因此界面也不同,因此并不真正相关.让我们称它们为IFooDevice和IBarDevice.随着时间的推移可能会添加更多设备类型 语言是C++.
由于其他组件(从现在开始称为客户端)可能想要使用其中一个或多个设备,因此我决定提供一个DeviceManager类来处理运行时对所有可用设备的访问.由于设备类型的数量可能会增加,我想平等对待所有设备(从经理的角度来看).但是,客户端将请求某种设备类型(或基于某些属性的设备).
我想到了两种可能的解决方案:
第一种是某种间歇层次结构.所有设备都将子类化一个公共接口IDevice,它将提供管理和设备查询所需的(虚拟)方法(如getProperties(),hasProperties(),...).然后,DeviceManager有一个指向IDevice的指针集合,在某些时候,需要从Base到Derived的转换 - 在管理器中使用模板方法或在客户端请求之后.
从设计的角度来看,我认为分离管理设备和特定设备本身的界面的问题会更加优雅.因此,它将导致两个不相关的接口:IManagedDevice和例如IFooDevice.真实设备需要从两者继承以便"成为"特定设备类型并且是可管理的.经理只管理指向IManagedDevice的指针.但是,如果客户端想要使用管理器提供的设备,则在某些时候需要在现在不相关的类之间(例如,从IManagedDevice到IFooDevice)之间进行转换.
我必须在这里选择两个邪恶中较小的一个吗？如果是这样的话会是哪一个？或者我会错过什么？
编辑:
关于"管理"部分.这个想法是让库提供各种不同的通信设备(客户端)应用程序可以使用和共享.管理仅仅归结为实例的存储,注册新设备和查找某个设备的方法.为任务选择"正确"设备的责任取决于客户端,因为它最了解它对通信的要求.为了重用并共享可用设备(并且我指的是真实实例而不仅仅是类),我需要一个到所有可用设备的中央访问点.我不太喜欢经理本身,但在这种情况下,这是我唯一能做到的.