Коллекция & л; Т > в сравнении со списком < T > что вы должны использовать на своих интерфейсах?
Слияние должно выполняться последовательно. В вашем случае объединение двух наборов изменений, которые не являются последовательными, небезопасно, потому что вы можете потерять изменения, которые могут быть сделаны для тех же файлов. Вот почему клиент TFS не позволяет вам это делать.
6 ответов
Ответить "почему" часть вопроса относительно того, почему не List<T>, причины соответствуют требованиям завтрашнего дня и простота API.
Соответствующий требованиям завтрашнего дня
List<T> не разработан, чтобы быть легко расширяемым путем разделения на подклассы его; это разработано, чтобы быть быстрым для внутренних реализаций. Вы заметите, что методы на нем не являются виртуальными и так не могут быть переопределены, и нет никаких рычагов в Add / Insert / Remove операции.
Это означает, что, если необходимо изменить поведение набора в будущем (например, отклонить несуществующие объекты, которые люди пытаются добавить или выполнить дополнительную работу, когда это происходит, такие как обновление состояния класса) тогда необходимо изменить тип набора, который Вы возвращаете одному, можно разделить на подклассы, который будет повреждающимся интерфейсным изменением (конечно, изменяющий семантику вещей как не разрешение пустого указателя, может также быть интерфейсное изменение, но вещи как обновление внутреннего состояния класса не были бы).
Так путем возврата или класса, который может быть легко разделен такой на подклассы как Collection<T> или интерфейс такой как IList<T>, ICollection<T> или IEnumerable<T>, можно изменить внутреннюю реализацию, чтобы быть различным типом набора для удовлетворения потребностей, не повреждая код потребителей, потому что это может все еще быть возвращено как тип, который они ожидают.
Простота API
List<T> содержит много полезных операций такой как [1 110], Sort и так далее. Однако, если это - набор, Вы представляете тогда, вероятно, что Вы управляете семантикой списка, а не потребителями. Таким образом, в то время как Вашему классу внутренне, возможно, понадобятся эти операции, очень маловероятно, что потребители Вашего класса хотели бы к (или даже должен) называть их.
По сути, путем предложения более простого класса набора или интерфейса, Вы уменьшаете число членов, которое пользователи Вашего API видят и облегчают для них использовать.
Я лично объявил бы, что он возвращает интерфейс, а не конкретный набор. Если Вы действительно хотите доступ списка, используйте IList<T> . Иначе рассмотрите ICollection<T> и IEnumerable<T> .
Это главным образом об абстракции Ваших собственных реализаций далеко вместо того, чтобы представить Объект списка, которым будут управлять непосредственно.
Это не хорошая практика для разрешения другим объектам (или люди) изменяют состояние объектов непосредственно. Думайте свойство, getters/setters.
Набор-> Для нормального набора
ReadOnlyCollection-> Для наборов, которые не должны быть изменены
KeyedCollection->, Когда Вы хотите словари вместо этого.
то, Как зафиксировать его, зависит от того, что Вы хотите, чтобы Ваш класс сделал и цель GetList () метод. Можно ли уточнить?
Я не думаю, что любой ответил, "почему" часть все же..., таким образом, здесь идет. Причина, "почему" "необходимо" использовать Collection<T> вместо List<T>, состоит в том, потому что, если Вы представляете List<T>, тогда любой, кто получает доступ к Вашему объекту, может изменить объекты в списке. Принимая во внимание, что Collection<T>, как предполагается, указывает, что Вы заставляете свое собственное "Добавить", "Удалите", и т.д. методы.
Вы, вероятно, не должны волноваться об этом, потому что Вы, вероятно, кодируете интерфейс для себя только (или возможно несколько коллег). Вот другой пример, который мог бы иметь смысл.
, Если у Вас есть общедоступный массив, исключая:
public int[] MyIntegers { get; }
Вы думали бы, что, потому что существует только "получить" средство доступа, которое никто не может смешать со значениями, но это не верно. Любой может изменить значения внутри там точно так же, как это:
someObject.MyIngegers[3] = 12345;
Лично, я просто использовал бы List<T> в большинстве случаев. Но если Вы разработаете библиотеку классов, которую Вы собираетесь выделить случайным разработчикам, и необходимо полагаться на состояние объектов... тогда, то Вы захотите сделать свой собственный Набор и заблокировать его по сравнению с там:)
В подобных случай я обычно пытаюсь представить наименьшее количество суммы implemententation, который необходим. Если потребители не должны знать, что Вы на самом деле используете список тогда, Вы не должны возвращать список. Путем возврата, поскольку Microsoft предлагает Набор, Вы скрываете то, что Вы используете список от потребителей Вашего класса и изолируете их против внутреннего изменения.
Хорошо класс Набора является действительно просто классом обертки вокруг других наборов для сокрытия их деталей реализации и других функций. Я считаю, что это имеет некоторое отношение к шаблону кодирования сокрытия свойства на объектно-ориентированных языках.
я думаю, что Вы не должны волноваться об этом, но если Вы действительно хотите нравиться инструменту анализа кода, просто сделать следующее:
//using System.Collections.ObjectModel;
Collection<MyClass> myCollection = new Collection<MyClass>(myList);