实现“继承广场”的最佳方法

enter image description here

的问题是在AgendaInstance（见红点）。我试图继承（重新使用）Agenda.Tasks以包含自己的任务，其类型为TaskInstance，子类型为Task。

我可以把this.Tasks.Add(new TaskInstance());放在AgendaInstance的里面。该代码有效，但当我尝试序列化或绑定时出现问题。由于Tasks静态绑定到Task所有被序列化（例如，到xml）或绑定（例如，到网格行）的属性是Task的属性，而不是TaskInstance。

有没有我可以用来解决这个问题的设计模式？我不想影响（新）Tasks在AgendaInstance。这将打破拥有继承层次的目的。我的midi-chlorians告诉我有一个解决方案比直接处理序列化或绑定细节要高;这是一个“更深层次”的问题，可以帮助他们获得更为基础的解决方案。我要去泛泛而谈，但也许你知道更好的方法或更好的模式。

来源

2015-04-07 toddmo

好像你可能想要使用一个通用类，比如'Agenda 其中T：ITask'，这样你的'AgendaInstance'类实际上是'AgendaInstance '，这样'Tasks'返回一个TaskInstance集合对象。 – zzzzBov

你可以做Agenda通用的Task，就像这样：

class Agenda<T> where T : Task { 
    public IList<T> Tasks {get; private set;} 
    ... 
} 
class AgendaInstance<TaskInstance> { 
    ... 
}

现在只有一个Task层次结构中的属性。然而，Agenda需要实例化一个类型参数，所以以前是“普通”Agenda变成Agenda<Task>。

来源

2015-04-07 02:27:19 dasblinkenlight

90％的xml序列化经验是不好的。他们倾向于打破继承模式，不支持接口。因此，它会导致你破解和修改现有的类以适应序列化。 XmlIgnore和重复的属性通常会在处理它时发生。

因此，通常我只为序列化目的创建另一个类。例如：AgendaSerializable，其中TaskSerializeable作为任务。好处是：您可以保持您的继承和数据模型清洁，而您需要以数据转换作为缺点来处理。

可能会与你同在。

来源

2015-04-07 02:46:05 Fendy

是的，这个xml序列化真的让这个类更加枯燥。最近我一直在阅读AOP，特别是PostSharp，因为你可以使用属性指出处理器（称为“方面”）的各种交叉问题，如日志记录，序列化，合同等。你把它放在一个单独的类中是非常正确的，我想编写一个处理xml序列化的'Aspect'。这个方面是一个单独的课程，也许我可以一般性地写，所以它可以用于任何课程！如果我有幸运和感谢，我会告诉你。 – toddmo

实现“继承广场”的最佳方法

回答

相关问题