Этот вопрос пришел в голову после прочтения ответа на этот вопрос; который в основном подчеркивал, что List<T> не имеет виртуальных методов, поскольку он был разработан, чтобы быть «быстрым, не расширяемым».
Если это цель дизайна, почему не было оригинального дизайна, включая герметизацию класса? (Я знаю, что сейчас это невозможно, поскольку это может сломать множество дочерних классов в клиентском коде)
Нет веских причин для его запечатывания. Получение из этого не вредит. Раньше я придерживался противоположного взгляда - оставляйте открытыми только те вещи, которые вы намеревались сделать для людей. Но в ретроспективе это не имеет смысла. .NET придерживается позиции, согласно которой методы по умолчанию не являются виртуальными, но классы по умолчанию открыты. List<T> просто следует той же практике.
Если вы хотите запечатать класс, то это тогда, когда он переопределяет виртуальные методы, но дальнейшее создание подклассов непросто или очевидно. Может быть немного полезно наследовать от коллекции, такой как Dictionary<TKey,TValue>, чтобы придерживаться параметров известного типа и избегать их ввода при использовании в приложении. Например, у вас может быть класс QueryString, производный от Dictionary<String,String>.
А поскольку виртуальных методов нет, действительно нечем защитить класс, запечатав его.
List<T> (и других общих коллекций), у меня нет проблем с решениями, принятыми командой BCL.
- person Josh; 25.01.2011
Должно быть много причин, по которым они решили не делать List<T> запечатанным, однако одна из возможностей состоит в том, что группа разработчиков Framework хотела паритета с ArrayList (который не запечатан), чтобы существующие программы и Frameworks, дизайн которых основан на расширении ArrayList, могли чтобы упростить обновление своих проектов для использования List<T>. Создание List<T> запечатанным было бы настоящим тупиком для этих целей, и одним из сильных руководящих решений при проектировании было бы позволить людям легко обновить свои существующие кодовые базы с ArrayList до List<T>.
List<T>, поскольку по умолчанию используется незапечатанный. Все, что им нужно было сделать, это не принять решение. Кроме того, они разработали Collection<T>, который будет производным от, чтобы он мог заменить ArrayList.
- person Gabe; 25.01.2011
List<T>, это могло бы вызвать раздражение у пользователей \ разработчиков фреймворка, которые полагались на расширение ArrayList. Это то, что они должны учитывать при принятии решений. Я слышал, ты ре. Collection<T> что интересно. Хотя вы можете добавить поведение к List<T> путем наследования и расширения, вы не можете должным образом переопределить поведение. Вы правы, Collection<T> гораздо лучше подходит для переопределения поведения. Я больше имел в виду расширение поведения. Но вы правильно подметили.
- person Tim Lloyd; 25.01.2011
List<T>для создания специализированной коллекции и добавления вспомогательных методов (например,List<Crayon>.Count(Color)), но может быть хорошей идеейsealнекоторые методы (Addи т. Д.). Кроме того, хотя .Net имеет несколько причуд, в целом это единый фреймворк. Кроме того, нельзя ли задать один и тот же вопрос для всех незапечатанных классов с невиртуальными методами? - person Kobi schedule 25.01.2011IList<T>,ICollection<T>илиIEnumerable<T>. Нет необходимости в наследовании, и тогда вы можете применить такие методы к любому списку / коллекции / перечислимому элементу правильного типа, а не только к экземплярам вспомогательного класса. Такие занятия обычно пахнут плохим дизайном. - person cdhowie schedule 25.01.2011ColorBoxв моем примере вместоList<Crayon>везде) - вы можете усложнить пример с помощью нескольких дополнительных элементов и свойств (например,Owner). Кроме того, помните, что методы расширения не существовали, когда вышел C # 2.0. (Я также стараюсь не создавать методы расширения для своих типов, я стараюсь использовать их для типов, которые иначе не могу расширить, но это другое обсуждение) - person Kobi schedule 25.01.2011List<T>поставлялся задолго до того, как появились методы расширения. Кроме того, какая альтернатива? Тот, кто плохо наследует отList<T>, вероятно, тоже плохо реализует альтернативу. - person Gabe schedule 25.01.2011ColorBox, вероятно, реализует некоторые другие интерфейсы, что упрощает работу, чемList<Color>. - person Cheng Chen schedule 25.01.2011