我的一位同事上周问我是否可以在C#中扩展泛型类的泛型类。他说这在C ++中是可能的。 他想要的东西确实有意义。他想要一个通用的装饰器来注释一个带有附加信息的任意类。类似的东西:
public class Decorator<T> : T
{
public object AdditionalInformation {get:set;}
}
这样他现在可以在任何地方使用这个通用装饰器而不是T。
我可以带来的最相似的东西是带有原始对象的容器类,附加信息和隐式转换。
public class Decorator<T>
{
private readonly T _instance;
public Decorator(T instance)
{
_instance = instance;
}
public T Instance
{
get { return _instance; }
}
public object AdditionalInformation { get; set; }
public static implicit operator T(Decorator<T> deco)
{
return deco._instance;
}
}
但这不一样,因为隐式转换只是一种方式。例如,他不能使用它作为方法的返回类型,因为在隐式转换后附加信息会丢失。
有没有人有更好的主意?
答案 0 :(得分:1)
如果您可以从某个基类派生所有可判断的类,那么您可以尝试在该基类中存储装饰器并使其信息可恢复。以下是保证包含一些错误的示例代码,但您可以理解。
public class Decorable
{
Dictionary<Type,object> decors = new Dictionary<Type,object>();
public void AddDecorator<D>(D decor) { decors[typeof(D)] = decor; }
public D GetDecorator<D>()
{
object value;
if (decors.TryGetValue(typeof(D), out value))
return (D)value;
else
return default(D);
}
}
public class Decorator<T> where T: class, Decorable
{
private readonly T _instance;
public Decorator(T instance)
{
_instance = instance;
instance.AddDecorator(this);
}
public T Instance
{
get { return _instance; }
}
public object AdditionalInformation { get; set; }
}
// use it like this
Decorator<MyClass> myDecor = myObj.GetDecorator<Decorator<MyClass>>();
如果无法派生,则必须将信息存储在某个静态类中。但是,正如wcoenen评论的那样,你需要清除这些信息,否则你会发生内存泄漏。清除是容易出错的,并不总是可行,因此最好采用第一种方法。例如(不是线程安全的,如果计划在多线程应用程序中使用它,则必须添加锁定):
static public class Decorators
{
static Dictionary<object,Dictionary<Type,object>> instance = new Dictionary<object,Dictionary<Type,object>>();
public static void AddDecorator<T,D>(this T obj, D decor)
{
Dictionary<Type,object> d;
if (!instance.TryGetValue(obj, out d))
{
d = new Dictionary<Type,object>();
instance.Add(obj, d);
}
d[typeof(D)]=decor;
}
public static D GetDecorator<T,D>(this T obj)
{
// here must be double TryGetValue, but I leave it to you to add it
return (D) instance[obj][typeof(D)];
}
public static T ClearDecorators(this T obj) { instance.remove(obj); }
}
// Decorator<T> code stays the same, but without type constraint