una sirve que protección propiedades propiedad programacion para nivel metodos declarar debido como clase atributos agregar accesible c# inheritance sealed

c# - sirve - ¿Por qué las clases no están selladas por defecto?



propiedades de una clase c# (9)

80% de las características de Word no se usan. 80% de las clases no se heredan de. En ambos casos, de vez en cuando, alguien viene y quiere usar o reutilizar una característica. ¿Por qué debería el diseñador original prohibir la reutilización? Permita que el reusuario decida qué quiere reutilizar.

Me preguntaba, dado que la existencia de la palabra clave sellada indica que la decisión del autor de la clase es si otras clases pueden heredar de ella, ¿por qué las clases no están selladas por defecto, con alguna palabra clave para marcarlas explícitamente como extensibles?

Sé que es algo diferente, pero los modificadores de acceso funcionan de esta manera. Con el valor predeterminado, el acceso más restrictivo y completo solo se otorga con la inserción de una palabra clave.

Sin embargo, hay una gran posibilidad de que no lo haya pensado bien, ¡por favor, sé humano!

El mero hecho de derivar de una clase no sellada no cambia el comportamiento de la clase. Lo peor que puede pasar es que una nueva versión de la clase base agregue un miembro con el mismo nombre que la clase derivada (en cuyo caso solo habrá una advertencia del compilador que diga que debe usar el modificador nuevo o de modificación) o la base la clase está sellada (que es un diseño no-no si la clase ya ha sido lanzada al aire libre). La subclasificación arbitraria aún cumple con el Principio de sustitución de Liskov .

La razón por la cual los miembros no son anulables por defecto en C # es porque anular un método puede cambiar el comportamiento de la clase base de una manera que el autor de la clase base no anticipó. Haciéndolo explícitamente abstracto o virtual, está diciendo que el autor es consciente de que puede cambiar o está fuera de su control y el autor debería haber tenido esto en cuenta.

Por la misma razón por la cual los objetos no son privados por defecto

o

para ser coherente con el objeto analógico, que es objetos no son privados por defecto

Simplemente adivinando, porque al final del día es la decisión de diseño de un idioma y lo que los creadores dicen es el material del canon.

Probablemente puedas hacer tantos argumentos a favor de sellados por defecto como puedas en contra de eso. Si fuera al revés, alguien estaría publicando la pregunta opuesta.

Veo dos razones simples:

  1. La herencia es un principio fundamental de OO, por lo que rechazarlo por defecto no sería intuitivo.
  2. La mayoría de las clases están diseñadas para permitir la herencia, por lo que al permitir la herencia de forma predeterminada, se ahorra tipeo.

Yo diría que fue solo un error. Conozco a muchas personas (incluyéndome a mí) que creen que las clases deberían estar selladas por defecto. Hay al menos un par de personas en el equipo de diseño de C # en ese campamento. El péndulo se ha alejado ligeramente de la herencia desde que se diseñó C # por primera vez. (Tiene su lugar, por supuesto, pero me resulta relativamente raro usarlo).

Por lo que vale, ese no es el único error en la línea de estar demasiado cerca de Java: personalmente preferiría que Equals y GetHashCode no estuvieran en el objeto, y que necesitaras instancias de Monitor específicas para el bloqueo también ...

las clases selladas previenen la herencia y, por lo tanto, son una abominación OO. mira esta diatriba para más detalles ;-)

En mi opinión, no debería haber sintaxis predeterminada, de esa manera siempre escribes explícitamente lo que deseas. Esto obliga al codificador a comprender / pensar más.

Si desea que una clase sea heredable, escriba

public extensible class MyClass

de otra manera

public sealed class MyClass

Por cierto, creo que lo mismo debería ir con los modificadores de acceso, no permitir los modificadores de acceso predeterminados.