这是动态类的情况还是......?
我什至不确定要搜索有关此问题的内容,所以我想我会将其发布在这里。
假设我有一堆接口,例如...
/// <summary>
/// All interesting classes will implement this interface
/// </summary>
interface IMasterInterface {}
/// <summary>
/// Interface to represent someone that creates / produces goods
/// </summary>
interface IProduceGoods : IMasterInterface { int Prop1 {get;} }
/// <summary>
/// Interface to represent someone that buys / consumes goods
/// </summary>
interface IConsumeGoods : IMasterInterface { int Prop2 {get;} }
/// <summary>
/// Interface to represent someone that stores goods
/// </summary>
interface IStoreGoods : IMasterInterface { double Prop3 {get;} string name {get;}}
/// <summary>
/// Interface to represent someone that enjoys looking at goods
/// </summary>
interface IEnjoyLookingAtGoods : IMasterInterface { int Prop4 {get;} DateTime Prop5 {get;} }
现在,我有一些我知道今天想要的组合,例如:
/// <summary>
/// Class to represent a farm which grows and stores crops
/// </summary>
class Farm : IProduceGoods, IStoreGoods {/*...*/}
/// <summary>
/// Class to represent a merchant who buys goods and stores them
/// </summary>
class Merchant : IConsumeGoods, IStoreGoods {/*...*/}
/// <summary>
/// Window Shopper represents someone who doesn't buy anything and only looks
/// </summary>
class WindowShopper : IEnjoyLookingAtGoods{ /*...*/ }
现在我很高兴我已经有了我的几个课程,但我认为明天不会最好还有一个有人实际上从商家那里购买的课程,所以我会转到我的代码并添加
/// <summary>
/// Princesses have lots of money to buy stuff and lots of time to look at stuff
/// </summary>
class Princess : IEnjoyLookingAtGoods, IConsumeGoods {/*...*/}
现在,我认为我不应该这样做......
我想做的是工厂(或类似)的东西并说:
IMasterInterface princess = MyFactory.Create(IEnjoyLookingAtGoods, IEnjoyLookingAtGoodsParameters, IConsumeGoods, IConsumeGoodsParameters)
/// This should be true
((princess is IEnjoyLookingAtGoods) && (princess is IConsumeGoods))
本质上,我会比如告诉工厂使用哪些接口来构造对象。我有包含 IMasterInterface 列表的容器
/// <summary>
/// My container class for interesting objects
/// </summary>
class InterestingObjectContainer
{ public ReadOnlyCollection<IMasterInterface> InterestingObjects {get;} }
现在,这就是问题的关键所在。让所有有趣的类实现 IMasterInterface 的原因是能够拥有一个 List 并使用更具体的接口作为过滤器。也许下面的内容会让它更清楚:
/// <summary>
/// I want to see the net population of producers and get there total production
/// </summary>
class ProducerProductionCalculator
{
// THIS IS WHERE THE MEAT OF THE QUESTION RESIDES!
ProductionResults Calculate(InterestingObjectContainer interestingObject)
{
List<IProduceGoods> producers = interestingObject.InterestingObjects.OfType<IProduceGoods>(); // Perhaps more interest LINQ
return DoSomethingWithListToAggregate(producers);
}
}
通过过滤出更具体的接口,我现在可以依赖传递给的所有对象 DoSomethingWithListToAggregate(ICollection 生产者) 具有 IProduceGoods 类的方法/属性。
我考虑过用字典和字符串属性查找来实现这一点,但感觉我可以用这种方式编写更强类型的代码,并确保某个地方的简单拼写错误不会把一切搞砸。
不管怎样,我想总结是:
这是在对象上实现变量属性的一种糟糕的方法吗?如果是的话,什么会更好。如果没有,有没有办法像我上面尝试解释的那样在工厂中创建对象?
编辑:
我认为这样做的想法有些好,这很酷。我想知道如何创建一个工厂,它接受一个仅具有属性的接口的参数,并且该属性仅具有 getters (我认为这是很重要的一点)以及属性的属性值,并返回一个实现该接口并具有所有属性的对象定义的属性。
例如,
/// <summary>
/// Factory to create any combination of properties
/// </summary>
class FactoryForInterestingObjects
{
public static IMasterInterface Create(
List<KeyValuePair</*what goes here is the interface that I want to use,
what goes here are the parameter values that
should be returned by the getter */>> );
}
我将向工厂传递所有接口及其参数值,它将创建一些实现这些接口并具有这些值的类。希望这更清楚一点?
编辑2:如何使用装饰器?
根据我对装饰器的了解,您可以扩展对象的功能。这很酷。但是,您必须提前知道如何扩展该功能。你不能随意这样做。
考虑到我的代码库如上所述,我想使用装饰器。
我会说:
// Edited to be correct
class EnjoyLookingDecorator : IEnjoyLookingAtGoods
{
private IMasterInterface instance;
public EnjoyLookingDecorator(IMasterInterface wrappedObject)
{ this.instance = wrapped Object;}
#region Implementation of IEnjoyLookingAtGoods
/*...*/
#endregion
}
编辑4:
我仍然认为这行不通。在您的示例中,我丢失了包含的类接口,我必须将其重定向。例如,
class EnjoyLookingDecorator : IEnjoyLookingAtGoods
{
private IMasterInterface instance;
public EnjoyLookingDecorator(IMasterInterface concrete)
{ this.instance = concrete;}
#region Implementation of IEnjoyLookingAtGoods here
/*...*/
#endregion
bool Is<T>() //this should be in the IMasterInterface
{
return this is T or instance is T;
}
}
class ConsumesGoodsDecorator : IConsumeGoods
{
private IMasterInterface instance;
public ConsumesGoodsDecorator (IMasterInterface concrete)
{ this.instance = concrete;}
#region Implementation of IConsumeGoods here
/*...*/
#endregion
bool Is<T>()
{
return this is T or instance is T;
}
}
当您
IMasterInterface princess = new MasterClass() //whatever your concrete type is named
princess = new ConsumesGoodsDecorator(new EnjoyLookingDecorator(princess))
不再可以执行 princess.PropertyOnIEnjoyLookingDecoratorInterface 时,您将丢失所有这些属性。这不是我想要的。保留属性的唯一方法是重定向
class ConsumesGoodsDecorator : IConsumeGoods, IEnjoyLookingAtGoods
{
private IMasterInterface instance;
public ConsumesGoodsDecorator (IMasterInterface concrete)
{ this.instance = concrete;}
#region Implementation of IConsumeGoods here
/*...*/
#endregion
#region Redirect all the IEnjoyLookingAtGoods Property Getters to instance
/* ... */
#endregion
bool Is<T>()
{
return this is T or instance is T;
}
}
通过执行重定向,我们必须实现接口。然后这些组合都必须有代码,这是我试图避免的。我对接口的组合没有限制。
编辑5:
也许我的问题仍然不清楚。想象一下上面的接口,并填充了它们的属性。
如果工厂可以做这样的事情:
/// <summary>
/// Factory to create any combination of properties
/// </summary>
class FactoryForInterestingObjects
{
public static IMasterInterface Create(
List<KeyValuePair<Type t, ArgSet customArguments>> interfaces))
{
object baseObject;
foreach(KeyValuePair<Type, ArgSet> interface in interfaces)
{
AddInterface(interface, object);
}
}
private static void AddInterface(KeyValuePair<Type, ArgSet> interface, ArgSet arguments)
{
// Delegate this to someone else
if(interface.Key is typeof(IProduceGoods))
{
IProduceGoodsExtensions.AddInterface(o, interface.value);
}
}
}
public static class IProduceGoodsExtensions
{
public static void AddInterface(object o, ArgSet arguments)
{
// do something to object to make it implement IProductGoods
// and make all the getters return the arguments passed in ArgSet
}
}
我意识到这不是它实际工作的方式,但说明了我想要表达的观点。我希望该对象实现接口的动态组合并具有设置器的默认值。
即使我可以做一些事情,比如让工厂编写一个包含代码的文本文件:
/// <summary>
/// Auto Generated by Factory to create a new type on the fly
/// </summary>
class ClassImplementingIProduceGoodsAndIEnjoyLookingAtGoods : IProduceGoods, IEnjoyLookingAtGoods
{
// From IProduceGoods
public int Prop1 {get; private set;}
// From IEnjoyLookingAtGoods
public int Prop4 {get; private set;}
public DateTime Prop5 {get; private set;}
public ClassImplementingIProduceGoodsAndIEnjoyLookingAtGoods(int prop1, int Prop4 , DateTime Prop5)
{
this.Prop1 = prop1; this.Prop4 = Prop4; this.Prop5 = Prop5;
}
}
然后编译该类并以某种方式允许我创建它的实例。这就是我正在寻找的。希望这更有意义。
编辑6:
这是我可能会采用的解决方案,因为我目前没有看到替代方案。
//Update Master Interface
interface IMasterInterface
{
bool Is(Type t);
IMasterInterface As(Type t);
}
/// <summary>
/// Class to build up a final object
/// </summary>
class CompositionObject : IMasterInterface
{
ICollection<IMasterInterface> parts;
CompositionObject(IMasterInterface object){ parts = new List<IMasterInterface(object);}
bool Is(Type t)
{
foreach(IMasterInterface part in parts)
{ if (part is t) return true; // not sure on this off top of head
}
return false;
}
IMasterInterface As(Type t)
{
foreach(IMasterInterface part in parts)
{ if(part is t) return part; }
}
bool Add(IMasterInterface interface)
{ this.Is(typeof(interface)) return false; // don't add again
this.parts.Add(interface) }
}
现在我的工厂可以返回这些组合对象,只要调用 As ,我就可以安全地向下转型。我觉得可能有一种方法可以使用泛型来避免强制转换。
任何实现 IMasterInterface 的具体类都可以在调用 As 时简单地返回自身。
编辑3:
感谢大家的评论。我很高兴我表达了我对模式的无知;D 感谢您的澄清!我喜欢这个网站和那里所有可爱的人!
I'm not really sure even what to search for regarding this issue, so I figured I'd post it here.
Let's say I have a bunch of interfaces like...
/// <summary>
/// All interesting classes will implement this interface
/// </summary>
interface IMasterInterface {}
/// <summary>
/// Interface to represent someone that creates / produces goods
/// </summary>
interface IProduceGoods : IMasterInterface { int Prop1 {get;} }
/// <summary>
/// Interface to represent someone that buys / consumes goods
/// </summary>
interface IConsumeGoods : IMasterInterface { int Prop2 {get;} }
/// <summary>
/// Interface to represent someone that stores goods
/// </summary>
interface IStoreGoods : IMasterInterface { double Prop3 {get;} string name {get;}}
/// <summary>
/// Interface to represent someone that enjoys looking at goods
/// </summary>
interface IEnjoyLookingAtGoods : IMasterInterface { int Prop4 {get;} DateTime Prop5 {get;} }
Now, I have some combination that I know I want today, something like:
/// <summary>
/// Class to represent a farm which grows and stores crops
/// </summary>
class Farm : IProduceGoods, IStoreGoods {/*...*/}
/// <summary>
/// Class to represent a merchant who buys goods and stores them
/// </summary>
class Merchant : IConsumeGoods, IStoreGoods {/*...*/}
/// <summary>
/// Window Shopper represents someone who doesn't buy anything and only looks
/// </summary>
class WindowShopper : IEnjoyLookingAtGoods{ /*...*/ }
Now I'm happy that I've got my few classes, but tomorrow, I think, wouldn't it be nice to also have a class where someone actually buys from the Merchant so I'd go to my code and add
/// <summary>
/// Princesses have lots of money to buy stuff and lots of time to look at stuff
/// </summary>
class Princess : IEnjoyLookingAtGoods, IConsumeGoods {/*...*/}
Now, I don't think I should have to do that...
What I would like to do is have a factory (or similar) thing and say:
IMasterInterface princess = MyFactory.Create(IEnjoyLookingAtGoods, IEnjoyLookingAtGoodsParameters, IConsumeGoods, IConsumeGoodsParameters)
/// This should be true
((princess is IEnjoyLookingAtGoods) && (princess is IConsumeGoods))
Essentially, I'd like to tell the factory which interfaces to use to construct the object. I have containers that have lists of IMasterInterface
/// <summary>
/// My container class for interesting objects
/// </summary>
class InterestingObjectContainer
{ public ReadOnlyCollection<IMasterInterface> InterestingObjects {get;} }
Now, here is where the meat of the question lies. The reason for having all the interesting classes implement the IMasterInterface was to be able to have a List and use the more specific interfaces as filters. Perhaps the following will make it more clear:
/// <summary>
/// I want to see the net population of producers and get there total production
/// </summary>
class ProducerProductionCalculator
{
// THIS IS WHERE THE MEAT OF THE QUESTION RESIDES!
ProductionResults Calculate(InterestingObjectContainer interestingObject)
{
List<IProduceGoods> producers = interestingObject.InterestingObjects.OfType<IProduceGoods>(); // Perhaps more interest LINQ
return DoSomethingWithListToAggregate(producers);
}
}
By filtering out to the more specific interface, I can now count on all the objects passed to
DoSomethingWithListToAggregate(ICollection producers)
having the methods / properties of the IProduceGoods class.
I thought about implementing this with dictionaries and string property look ups, but it feels like I can write more strongly typed code this way and ensure that a simple spelling mistake somewhere is not going to mess everything up.
Anyway, I guess the summary is:
Is this a poor way of implementing variable properties on a object and if so what would be a better. If not, is there a way to create the objects in a factory as I have tried to explain above?
EDIT:
I see some oks to the idea of doing this, and that's cool. I was wondering how to create a factory that takes arguments of an interface which only has properties and the properties only have getters (I think that's an important point) along with property values for the properties and returns a object that implements the interface and has all the properties defined.
For instance,
/// <summary>
/// Factory to create any combination of properties
/// </summary>
class FactoryForInterestingObjects
{
public static IMasterInterface Create(
List<KeyValuePair</*what goes here is the interface that I want to use,
what goes here are the parameter values that
should be returned by the getter */>> );
}
I'd pass the factory all the interfaces and their parameter values and it would create some class that implements those interfaces and has those values. Hopefully this is a little more clear?
EDIT 2: How to use Decorator?
From what I see about the decorator, you can extend the functionality of an object. That's cool. However, you have to know ahead of time how you are extending that functionality. You cannot do this arbitrarily.
Consider that my code base is as above and I want to use decorator.
I'd say:
// Edited to be correct
class EnjoyLookingDecorator : IEnjoyLookingAtGoods
{
private IMasterInterface instance;
public EnjoyLookingDecorator(IMasterInterface wrappedObject)
{ this.instance = wrapped Object;}
#region Implementation of IEnjoyLookingAtGoods
/*...*/
#endregion
}
EDIT 4:
I still don't think that'll work. In your example, I lose the contained classes interface, I have to redirect it down. For instance,
class EnjoyLookingDecorator : IEnjoyLookingAtGoods
{
private IMasterInterface instance;
public EnjoyLookingDecorator(IMasterInterface concrete)
{ this.instance = concrete;}
#region Implementation of IEnjoyLookingAtGoods here
/*...*/
#endregion
bool Is<T>() //this should be in the IMasterInterface
{
return this is T or instance is T;
}
}
class ConsumesGoodsDecorator : IConsumeGoods
{
private IMasterInterface instance;
public ConsumesGoodsDecorator (IMasterInterface concrete)
{ this.instance = concrete;}
#region Implementation of IConsumeGoods here
/*...*/
#endregion
bool Is<T>()
{
return this is T or instance is T;
}
}
so when you d
IMasterInterface princess = new MasterClass() //whatever your concrete type is named
princess = new ConsumesGoodsDecorator(new EnjoyLookingDecorator(princess))
you no longer can do princess.PropertyOnIEnjoyLookingDecoratorInterface you lose all those properties. This is not what I want. The only way to preserve the properties is to redirect
class ConsumesGoodsDecorator : IConsumeGoods, IEnjoyLookingAtGoods
{
private IMasterInterface instance;
public ConsumesGoodsDecorator (IMasterInterface concrete)
{ this.instance = concrete;}
#region Implementation of IConsumeGoods here
/*...*/
#endregion
#region Redirect all the IEnjoyLookingAtGoods Property Getters to instance
/* ... */
#endregion
bool Is<T>()
{
return this is T or instance is T;
}
}
By doing the redirect, we have to implement the interface. Then the combinations have to all have code, which is what I'm trying to avoid. I don't to have constraints on the combinations of interfaces.
EDIT 5:
Perhaps I'm still not clear in my question. Imagine the interfaces as they are above with their properties filled in.
If the factory could do something like this:
/// <summary>
/// Factory to create any combination of properties
/// </summary>
class FactoryForInterestingObjects
{
public static IMasterInterface Create(
List<KeyValuePair<Type t, ArgSet customArguments>> interfaces))
{
object baseObject;
foreach(KeyValuePair<Type, ArgSet> interface in interfaces)
{
AddInterface(interface, object);
}
}
private static void AddInterface(KeyValuePair<Type, ArgSet> interface, ArgSet arguments)
{
// Delegate this to someone else
if(interface.Key is typeof(IProduceGoods))
{
IProduceGoodsExtensions.AddInterface(o, interface.value);
}
}
}
public static class IProduceGoodsExtensions
{
public static void AddInterface(object o, ArgSet arguments)
{
// do something to object to make it implement IProductGoods
// and make all the getters return the arguments passed in ArgSet
}
}
I realize this is not how it will actually work, but illustrates the point I'm trying to make. I want the object to implement a dynamic combination of interfaces and have default values for the setters.
Even if I could do something like have the factory write a text file containing the code:
/// <summary>
/// Auto Generated by Factory to create a new type on the fly
/// </summary>
class ClassImplementingIProduceGoodsAndIEnjoyLookingAtGoods : IProduceGoods, IEnjoyLookingAtGoods
{
// From IProduceGoods
public int Prop1 {get; private set;}
// From IEnjoyLookingAtGoods
public int Prop4 {get; private set;}
public DateTime Prop5 {get; private set;}
public ClassImplementingIProduceGoodsAndIEnjoyLookingAtGoods(int prop1, int Prop4 , DateTime Prop5)
{
this.Prop1 = prop1; this.Prop4 = Prop4; this.Prop5 = Prop5;
}
}
Then compile the class and somehow allow me to create instances of it. That's what I'm looking for. Hopefully that makes more sense.
EDIT 6:
This is the solution I'll probably go with since I'm not seeing an alternative at this point.
//Update Master Interface
interface IMasterInterface
{
bool Is(Type t);
IMasterInterface As(Type t);
}
/// <summary>
/// Class to build up a final object
/// </summary>
class CompositionObject : IMasterInterface
{
ICollection<IMasterInterface> parts;
CompositionObject(IMasterInterface object){ parts = new List<IMasterInterface(object);}
bool Is(Type t)
{
foreach(IMasterInterface part in parts)
{ if (part is t) return true; // not sure on this off top of head
}
return false;
}
IMasterInterface As(Type t)
{
foreach(IMasterInterface part in parts)
{ if(part is t) return part; }
}
bool Add(IMasterInterface interface)
{ this.Is(typeof(interface)) return false; // don't add again
this.parts.Add(interface) }
}
Now my factory can just return these composition objects and as long as As is called, I can then downcast safely. I feel like there's probably a way to use generics to avoid the casting.
Any concrete classes implementing IMasterInterface can simply return themselves when As is called.
EDIT 3:
Thanks to everyone for comments. I'm glad I posted my ignorance of the pattern ;D Thanks for the clarification! I love this site and all you lovely people out there!!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
尝试研究装饰设计模式。据我所知,它适用于您想到的那种情况,即可以包含从一组属性中提取的一组混合属性的对象。在装饰器模型中,每个属性都是它自己的一个类,您可以有效地动态连接这些类以创建具有所需属性的对象。
要实现过滤,您需要某种迭代器来遍历装饰器链,以查看您要查找的装饰器是否包含在您正在测试的对象中。
我没有在 C# 中使用过 Decorator,只在 C++ 中使用过,但我发现它是一种非常有用且灵活的前进方式。如果您发现自己创造了更多&更专业的类代表“属性”类的交集,那么我认为装饰器可能会很有帮助。
有关此模式的信息,请参阅C# 中的装饰器设计模式。 (并购买并阅读《GoF 设计模式》一书!)
Try looking into the Decorator Design Pattern. As far as I can see it is intended for the sort of case you have in mind, i.e. objects which can contain a mixed set of properties drawn from a set of properties. In the Decorator model, each property is a class of its own, and you effectively concatenate these classes dynamically to create objects with the properties you want.
To implement the filtering, you'd need to have some sort of iterator to walk the chain of Decorators to see if the one you are after is included for the object you are testing.
I haven't used Decorator in C#, only C++, but I have found it a very useful and flexible way forwards. If you find yourself creating more & more specialised classes which represent intersections of 'property' classes then I think Decorator may well help.
See Decorator Design Pattern in C# for info on this pattern. (And buy and read the GoF Design Patterns book!)
根据您的更新,我发现您似乎不理解装饰器模式。
我不知道这是否是最好的方法,就好像您的行为没有任何差异并且您的接口是静态的(IenjoyLookingAtGoods、IConsumeGoods 等)您可以继续并使用抽象上的属性来实现这些输入,然后通过设置它们来创建新实例。
装饰器应该是这样的
,如果你想得到实现两者的东西,你需要做这样的事情:
编辑-
你可以像这样破解它:
但这很令人讨厌,我读你的问题最多,最似乎这些接口没有意义。您根本没有添加行为。
如果您不希望公主拥有 IProduceGoods,那么为什么不拥有一个实现 IMasterInterface 并具有 4 个具有不同接口(组合)的属性的类,请将其设置为 null。 仍然很难弄清楚
如果没有上下文HTH
based on your update I see that you don't seem to understand the decorator pattern.
I don't know if this is the best way to go yet, as if you don't have any difference in behaviour and your interfaces are static (IenjoyLookingAtGoods, IConsumeGoods, etc) you can go ahead and implement these with properties on your abstract type, and just create new instances by setting them.
The decorators should be something like this
and if you want to get something that implements both you need to do something like this:
EDIT-
you could hack it like this:
but this is nasty, the most I read your question, the most seems that those interfaces make no sense. You are not adding behaviour at all.
Why not have a class that implements IMasterInterface, and has 4 properties with the different interfaces (composition), if you don't want a princess to have IProduceGoods then set that as null. Still is hard to figure out without context
HTH
我不喜欢 IMasterInterface 概念,但假设您只是使用抽象术语来表达问题 - 我可以看到这一点。我对你的例子中的用法也有一个小小的疑问:
“公主”不应该是“喜欢看起来和消费商品的东西”吗?
除此之外,我认为过滤实现的接口类型的方法很好。
I don't like the IMasterInterface concept, but assuming that you're just using an abstract term for the question - I can see past that. I also have a niggling doubt about the usage in your example:
Shouldn't "princess" should be "somethingthatlikestolooksandconsumegoods"?
Other than that, I think the approach of filtering on the types of interface implemented is fine.
这是一个好办法。而且,坦率地说,我不认为它有任何问题。接口只是接口 - 它们仅提供一种描述一组公共成员的方法。问题是你的问题很笼统,很难理解你想要实现的目标。
接受接口的工厂方法很奇怪。例如,我们有以下代码:
工厂会创建什么? A 或 B 的实例?
无论如何,我认为我能提出的最好建议是:不要想太多。
This is a good way. And, frankly, I do not see any problems with it. Interfaces are just interfaces - they only provide a way to describe a set of common members. The problem is that your question is quite generic and it is hard to understand what you are trying to achieve.
The factory method accepting interfaces is quite weird. For example we have the following code:
What would the factory create? Instance of A or B?
Anyway, I think that the best advise I can come up with is: Don't overthink it.
回答有关工厂的问题,您可以使用反射和/或原型模式来完成,但前提是接口的组合是唯一的。如果您有多个具体类可以满足所请求的接口列表(例如,Prices 和 Prince 类),那么工厂将无法知道要创建哪一个。
如果没有具体的类,并且您确实尝试在运行时创建/组合/等对象,那么那就是一匹不同颜色的马。您可能需要一个公共基类(或者可能在您的主界面中提供支持)来协助使用(正如另一张海报所建议的)装饰器方法,或者可能使用构面类型模式。
Answering the question abouth the factory, you could use reflection and/or the prototype pattern to accomplish, but only if the combination of interfaces is unique. If you have more than one concrete class that can satisfy the list of requested interfaces (say, classes Pricess and Prince) then the factory would have no way to know which to create.
If there are no concrete classes, and you are truely trying to create/compose/etc an object at runtime then that is a horse of a different color. You would likely need a common base class (or perhaps support in your master interface) to assist with this using (as another poster suggested) a decorator approach, or perhaps using a facet-type pattern.