Вопрос: Коллекция, которая наследуется от ObservableCollection. Каковы преимущества?


Посмотрев на эта статья MSDN , Теперь я задаюсь вопросом, какая польза, если таковая имеется, заключается в определении коллекции как класса, который наследуется от 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());
    }
}

Что-то я здесь не замечаю?


5


источник


Ответы:


Одним из основных преимуществ является то, что вы можете определить 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>

Наконец, (и это просто вопрос вкуса, я полагаю), это не повредит вообще и может помочь. Иногда вам требуется больше методов / свойств для данного типа коллекции. Приятно иметь готовый подкласс, без необходимости рефакторинга.


9



Пример далек от хорошего использования для наследования, что особенно мало добавляет к классу.

Как правило, вы можете думать о подклассификации его так же, как и для любого другого класса, когда он предоставляет полезные функции, но вам нужно что-то большее. Например, вам может потребоваться конкретное действие для вставки, некоторая специальная обработка, реализация дополнительного интерфейса или другое уведомление, затем вы наследуете и переопределяете / добавляете элементы по мере необходимости.

Практический пример выполнен в среде MVVM для WPF Caliburn.Micro , где они BindableCollection<T>, наследующий от ObservableCollection<T>, который выполняет маршрутизацию пользовательского интерфейса потока в дополнение к уведомлению об изменениях.


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 <T>?»


1