我们在使用 Composite 模式组织设备管理时,对现实中的设备进行抽象是很大的挑战.我们会设计一个基类,然后根据设备的特性设计各种类型的设备的继承关系,然后各种设备再继承这些子类.(标准OOP设计)
其实在面向对象的编程中,使用继承本身就有很大的挑战,我们必须把基类设计的很稳定,基类的稳定性和我们对对象的了解和对对象未来变化的了解有直接的关系,我们必须使我们的基类在适应未来的变换没有大的修改,这样才能减少因为对基类的修改对继承类的影响.
这就象我们用积木摆一个倒三角型(∨),在面对现实中千差万别的设备和未来会出现的设备时,很难维持这个类的模型.
另外过多的类和继承关系本身对 Composite 模式对象的管理也是一种挑战(比如使用 Vistor 模式).
把对设备的管理和设备本身的抽象分开是一个很好的解决办法.
实际上我们在实际设计中使用了 Bridge 模式.
首先我们定义了一个接口
public interface IDeviceDriver
{
......// 定义对设备的基本操作方法
}
然后在 Device 类里添加一个属性
IDeviceDriver DeviceDriver { get;}
这样,我们就把对设备的抽象从设备本身分离开,由实现 IDeviceDriver 或继承接口的设备驱动类负责对设备的操作.
使用 Birdge 模式把设备的抽象分离出来后,在设备管理中我们只要维持很少的类和继承关系.
Component 类,DeviceNode 类和Device 类.为了管理的方便添加了 DeviceRootNode 类,他继承 DeviceNode 类,
只是重写 Parent 属性,使他指向一个空引用.作为所有对象的顶层父对象
这样,我们在用 Composite 模式实现设备管理时,只维持了4个类.极大简化了代码.
为了扩展系统的使用,我们公开 IDeviceDriver 接口,允许用户实现 IDeviceDriver 接口来开发特定设备的驱动程序.
其实在面向对象的编程中,使用继承本身就有很大的挑战,我们必须把基类设计的很稳定,基类的稳定性和我们对对象的了解和对对象未来变化的了解有直接的关系,我们必须使我们的基类在适应未来的变换没有大的修改,这样才能减少因为对基类的修改对继承类的影响.
这就象我们用积木摆一个倒三角型(∨),在面对现实中千差万别的设备和未来会出现的设备时,很难维持这个类的模型.
另外过多的类和继承关系本身对 Composite 模式对象的管理也是一种挑战(比如使用 Vistor 模式).
把对设备的管理和设备本身的抽象分开是一个很好的解决办法.
实际上我们在实际设计中使用了 Bridge 模式.
首先我们定义了一个接口
public interface IDeviceDriver
{
......// 定义对设备的基本操作方法
}
然后在 Device 类里添加一个属性
IDeviceDriver DeviceDriver { get;}
这样,我们就把对设备的抽象从设备本身分离开,由实现 IDeviceDriver 或继承接口的设备驱动类负责对设备的操作.
使用 Birdge 模式把设备的抽象分离出来后,在设备管理中我们只要维持很少的类和继承关系.
Component 类,DeviceNode 类和Device 类.为了管理的方便添加了 DeviceRootNode 类,他继承 DeviceNode 类,
只是重写 Parent 属性,使他指向一个空引用.作为所有对象的顶层父对象
这样,我们在用 Composite 模式实现设备管理时,只维持了4个类.极大简化了代码.
为了扩展系统的使用,我们公开 IDeviceDriver 接口,允许用户实现 IDeviceDriver 接口来开发特定设备的驱动程序.
