我正在开发一个库,其中有两组类:
A)几个已经用代码编写的类,这些类有一堆函数或“动作”
B)一些在实例化时必须“配置”的类,以便使用我的库的用户可以实例化第二组类中的对象,并“分配”第一组中的操作
现在我使用的是委托,如下所示:
在代码中,我声明了一些A和B使用的委托:
public delegate void Action03(int value);
然后我在组A中实现了“操作”:
public Delegates.Action03 DoSomething03 = delegate(int value) { [code to execute when this action is specified on the constructor] };
最后,我们使用下面这样的构造函数来实例化来自组B的对象,在组B中,我们将所需的委托/操作作为参数进行传递:
public SomethingGroupB(Delegates.Action03 act03) { ... }
当然,我们可以实例化作为参数传递委托的对象:
SomethingGroupB somthg1 = new SomethingGroupB(GrpA01.DoSomething03);
但重点是,我们可以实例化类似的对象,但分配不同的操作:
SomethingGroupB somthg2 = new SomethingGroupB(GrpA07.DoSomething03);
SomethingGroupB somthg3 = new SomethingGroupB(GrpA01.DoSomething01);
SomethingGroupB somthg4 = new SomethingGroupB(GrpA02.DoWhatever);
所以..。总而言之,我希望预编码(在我的库中)操作,并且用户必须在实例化新对象时选择分配给它的操作,并且这些操作不会改变。
我想我也可以用事件来做这件事,但我不需要添加和删除“动作”,它们在每个类型B的对象的整个生命周期内都是固定的。
所以我的问题是:有没有比我用委托实现的解决方案更好、更好、更干净的解决方案呢?
非常感谢!
发布于 2012-03-06 21:25:11
所以我的问题是:有没有比我用委托实现的解决方案更好,更好,更干净的解决方案?
我建议的一个改进是使用框架中定义的委托,而不是定义自己的委托。例如,您的Action03
委托只是一个System.Action
。这将在使API更容易被发现方面提供更多的可用性。
也就是说,这是在有效地使用委托来实现Strategy pattern。如果这提供了您所需的全部功能,那么在这里它可能是一个很好的选择,而且相当干净。
发布于 2012-03-06 21:23:19
我认为委托是唯一的选择。
也许你也可以使用装饰器模式,如果它适合你的需要?它非常干净,因为它是一种模式,它的标准,并且“易于”理解,因为它在某种程度上是规范化的。
难道不能想出其他的方法吗?也许可以避免大量使用对象组合(然后在运行时将对象链接在一起,这可能会更简单一些?
https://stackoverflow.com/questions/9592023
复制相似问题