cref - remarks c#

¿Por qué la Lista<T> no está sellada?

Question

Esta pregunta vino a la mente después de leer la respuesta a this pregunta; que básicamente señaló que la List<T> no tiene métodos virtuales, ya que fue diseñada para ser "rápida, no extensible".

Si ese es el objetivo del diseño, ¿por qué el diseño original no incluyó el sellado de la clase? (Sé que eso no es posible ahora, viendo cómo eso rompería muchas clases secundarias dentro del código del cliente)

Answer 1

Debe haber muchas razones por las que decidieron no sellar la List<T> , sin embargo, una posibilidad es que el equipo de diseño de Framework deseaba la paridad con ArrayList (que no está sellada) para que los programas y Frameworks existentes que tenían diseños basados ​​en extender ArrayList sería capaz de actualizar más fácilmente sus diseños para usar la List<T> . Hacer la List<T> sellada habría sido un verdadero callejón sin salida para estos usos y una de las opciones de diseño de guía sólida habría sido permitir que las personas actualicen fácilmente sus bases de códigos existentes de ArrayList a List<T> .

Answer 2

No hay ninguna razón convincente para sellarlo. No hace daño derivar de ello. Solía ​​ser de la mentalidad opuesta: solo deja las cosas sin sellar de las que pretendes derivar. Pero en retrospectiva, no tiene sentido. .NET toma la posición de que los métodos no son virtuales por defecto, pero las clases no están selladas por defecto. List<T> simplemente sigue la misma práctica.

El lugar donde desea sellar una clase es cuando anula los métodos virtuales, pero la subclasificación adicional no es fácil u obvia. Puede ser un poco útil derivar de una colección como Dictionary<TKey,TValue> para mantener parámetros de tipo conocido y evitar escribirlos si se utilizan en una aplicación. Por ejemplo, tal vez tendría una clase QueryString que se deriva de Dictionary<String,String> .

Y como no hay métodos virtuales, realmente no hay nada contra lo que proteger a la clase al sellarla.