在查看this MSDN article后,我现在想知道将集合定义为继承自ObservableCollection
的类的好处是什么。这之间是否有任何显着差异:
class MyCollection : ObservableCollection<MyObject> { }
class Class1
{
private MyCollection _newCollection = new MyCollection();
public Class1()
{
_newCollection.Add(new MyObject());
}
}
和此:
class Class1
{
private ObservableCollection<MyObject> _newCollection = new ObservableCollection<MyObject>();
public Class1()
{
_newCollection.Add(new MyObject());
}
}
我在这里有什么东西可以忽略吗?
答案 0 :(得分:10)
一个主要好处是您可以定义Add
函数,这使得内联初始化更容易。例如:
class MyCollection : ObservableCollection<MyObject>
{
public void Add(string prop1, string prop2)
{
base.Add(new MyObject { Prop1 = prop1, Prop2 = prop2 });
}
}
让你写下这个:
MyCollection collection = new MyCollection
{
{ "prop1", "prop2" },
{ "prop1", "prop2" },
};
第二个(相关的)好处:如果您正在使用XAML,那么使用子类集合可以将集合实例(用于设计/测试用例)定义为标记,如:
<local:MyCollection xmlns:local="MyNamespace">
<local:MyObject Prop1="prop1" Prop2="prop2" />
<local:MyObject Prop1="prop1" Prop2="prop2" />
</local>
最后,(这只是一个品味的问题,我想)它一般不会受到伤害,并且可以提供帮助。有时您最终需要更多给定集合类型的方法/属性。很高兴有一个类型化的子类准备好,而不需要重构。
答案 1 :(得分:2)
在您给出的示例中,没有特别的好处。一般来说,我认为如果你没有以某种方式扩展或覆盖继承的类,通常应该避免继承。话虽如此,您的样本并不完全忠实于文章中的样本。
public class NameList : ObservableCollection<PersonName>
{
public NameList() : base()
{
Add(new PersonName("Willa", "Cather"));
Add(new PersonName("Isak", "Dinesen"));
Add(new PersonName("Victor", "Hugo"));
Add(new PersonName("Jules", "Verne"));
}
...
在MSDN示例中,他们在类构造函数中添加了其他逻辑。在一个现实世界的例子中,这个类可能有一个构造函数,它接受了某种类型的存储库接口,或从文件中读取,或者不属于ObservableCollection功能的任何数量的东西。所以原始问题的答案是另一个问题“你需要扩展ObservableCollection&lt; T&gt;?”
答案 2 :(得分:2)
这个例子远不是继承的良好用法,特别是对该类几乎没有任何作用。
通常情况下,当你提供有用的功能但你想要更多的东西时,你可以想到以与其他任何类相同的方式对它进行子类化。例如,您可能需要一个特定的操作来进行插入,一些特殊处理,实现一个额外的接口或一些不同的通知,然后你继承,并根据需要覆盖/添加成员。
一个实际的例子是在WPF Caliburn.Micro的MVVM框架中完成的,它们具有BindableCollection<T>
,继承自ObservableCollection<T>
,除了通知有关更改之外,它还执行线程UI编组。 / p>