Этот вопрос пришел на ум после прочтения ответа на этот вопрос; который в основном сделал вывод, что List<T> не имеет виртуальных методов, поскольку он был разработан как "быстрый, а не расширяемый".
Если это цель дизайна, почему первоначальный дизайн не включал в себя герметизацию? (Я знаю, что это невозможно сейчас, видя, как это сломает много дочерних классов в клиентском коде)
Там нет веских причин, чтобы запечатать его. Это не причиняет вреда от этого. Раньше я придерживался противоположного мышления - оставляйте вещи незапечатанными, которые вы собираетесь использовать для людей. Но в ретроспективе это бессмысленно..NET принимает позицию о том, что методы не виртуальны по умолчанию, но классы по умолчанию не распечатываются. List<T> просто следует этой же практике.
Если вы хотите заархивировать класс, это когда он переопределяет виртуальные методы, но дальнейшее подклассирование не является простым или очевидным. Может быть немного полезно извлечь из коллекции, такой как Dictionary<TKey,TValue>, чтобы придерживаться известных параметров типа и не вводить их, если они используются в приложении. Например, возможно, у вас будет класс QueryString, который происходит от Dictionary<String,String>.
И поскольку нет виртуальных методов, на самом деле нет ничего, чтобы защитить класс от его герметизации.
Должно быть много причин, по которым они решили не закрывать List<T>, однако одна из возможностей заключается в том, что команда разработчиков Framework хотела паритет с ArrayList (который не был запечатан), чтобы существующие программы и Frameworks, которые имели проекты основанный на расширении ArrayList, сможет более легко модернизировать свои конструкции, чтобы использовать List<T>. Создание List<T> запечатанного было бы настоящим тупиком для этих целей, и один из сильных вариантов дизайна мог бы позволить людям легко обновить существующие кодовые базы от ArrayList до List<T>.