我正在开发一个库,其中我有两组课程:
A)几个带有一堆函数或“动作”的类,已经用代码
编写B)在实例化时必须“配置”的几个类,其方式是使用我的库的用户可以从第二组类中实例化对象并从第一组“分配”动作
现在我正在使用代表,就像这样:
代码中的Somwhere我声明了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组中的对象,我们将参数作为参数传递给我们想要的委托/动作:
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类的每个对象的整个生命周期中都是固定的。
所以我的问题是:是否有比我与代表实施的更好,更好,更清洁的解决方案?
非常感谢!
答案 0 :(得分:2)
所以我的问题是:是否有比我与代表实施的更好,更好,更清洁的解决方案?
我建议的一个改进是使用框架中定义的委托,而不是定义自己的委托。例如,您的Action03
代表只是System.Action<int>
。这样可以提高API的可用性。
话虽如此,这实际上是使用代理来实现Strategy pattern。如果这提供了您需要的全部功能,那么它可能是一个很好的选择,而且相当干净。
答案 1 :(得分:0)
我认为代表是唯一的出路。
也许你也可以使用装饰模式,如果它适合你的需要?它非常干净,因为它的模式,标准和“易于”理解,因为它在某种程度上是标准化的。
不能想到任何其他方式,可能是因为更多地使用对象组合(然后在运行时将对象链接在一起,这可能会更多一些?