¿Alguna vez puede tener demasiados métodos "virtuales protegidos"?

Question

Aquí hay una pregunta para aquellos de ustedes con experiencia en proyectos más grandes y diseño de API / framework.

Estoy trabajando en un marco que será utilizado por muchos otros proyectos en el futuro, por lo que quiero que sea agradable y extensible, pero al mismo tiempo debe ser simple y fácil de entender.

Sé que mucha gente se queja de que .NET Framework contiene demasiadas clases selladas y miembros privados. ¿Debo evitar esta crítica y abrir todas mis clases con muchos miembros virtuales protegidos?

¿Es una buena idea hacer tantos de mis métodos y propiedades protegidos virtuales como sea posible? ¿En qué situaciones evitaría virtual protegido y haría que los miembros sean privados.

Answer 1

Su clase incluye miembros de datos; Los métodos que realizan operaciones internas básicas en aquellos miembros de datos donde la funcionalidad nunca debe cambiar siempre deben ser privados. Por lo tanto, los métodos que realizan operaciones básicas con sus miembros de datos, como la inicialización y la asignación, deben ser privados. De lo contrario, corre el riesgo de "segundo orden". clases derivadas que obtienen un conjunto incompleto de comportamientos habilitados; los primeros miembros derivados podrían redefinir potencialmente el comportamiento de la clase.

Dicho todo esto, creo que debes tener mucho cuidado al definir métodos como "virtual protegido". Tendría mucho cuidado al definir métodos como "virtual protegido", porque hacerlo no solo declara la posibilidad de anular la funcionalidad, sino que de alguna manera define una expectativa de funcionalidad anulada. Eso me parece un conjunto de comportamientos poco definidos para anular; Prefiero tener un conjunto bien definido de comportamientos para anular. Si desea tener un conjunto muy amplio de comportamientos reemplazables, preferiría estudiar la Programación Orientada a Aspectos, que permite ese tipo de cosas de una manera muy estructurada.

Answer 2

Cuando marca un método con la palabra virtual, permite que los usuarios cambien la forma en que se ejecuta esa lógica. Para muchos propósitos, eso es exactamente lo que quieres. Creo que ya lo sabes.

Sin embargo, los tipos deben diseñarse para este tipo de extensión. Debe elegir activamente los métodos, donde tiene sentido permitir que el usuario cambie el comportamiento. Si solo aplica virtual en todo el lugar, corre el riesgo de arruinar la integridad del tipo, realmente no ayuda al usuario a comprender el tipo y puede introducir una serie de errores, incluidos problemas relacionados con la seguridad.

Prefiero el enfoque conservador. Marco todas mis clases con sellado a menos que específicamente quiera habilitar la herencia y en esos (pocos) casos solo hago que los métodos necesarios sean virtuales.

Es fácil eliminar la etiqueta sellada si la clase necesita cambiar para permitir la herencia en el futuro. Sin embargo, si desea cambiar una clase, que ya se está utilizando como clase base para algún otro tipo, corre el riesgo de romper la subclase cuando cambia la clase base.

Answer 3

Mi punto de vista es:

• Si puede usar eventos , es preferible a los métodos protegidos .
• Intente evitar los métodos protegidos como sea posible, si no es posible, entonces debe usarlo ;-).

Answer 4

Elegir protegido sobre privado es una decisión de diseño deliberada. Está declarando que su clase admite explícitamente el uso de esa función, con todos los gastos generales (diseño y esfuerzo de implementación) que conlleva. Solo usaría protected en aquellas situaciones en las que sé que es necesario, en gran parte porque lo estoy haciendo yo mismo. (También encontrará comentarios de los desarrolladores de BCL en la misma línea que lo que he dicho).

La diferencia de rendimiento virtual / non- virtual es irrelevante en cualquier máquina que sea lo suficientemente potente como para ejecutar .NET Framework.

Answer 5

No, no puedes tener "demasiados". Sin embargo, la idea de que deberíamos hacer todo protegido en lugar de privado o evitar "sellado" a toda costa es una tontería. Mantendría "métodos auxiliares" y estructuras de datos internos privados.

Answer 6

  

¿Es una buena idea hacer que tantos de mis métodos y propiedades protegidos virtuales como sea posible?

No es tan buena idea.

Los métodos virtuales protegidos proporcionan puntos de extensibilidad en el marco al tiempo que agregan acoplamiento.

Existen técnicas más prometedoras para proporcionar extensibilidad: Composición y Delegación .