¿Por qué se debe evitar la herencia de forma?

Recuerdo haber aprendido VB4 y arrastrar un botón a un formulario, hacer doble clic en ese botón y escribir código en el controlador de eventos con el que acababa de ser bendecido mágicamente. Viniendo de QBASIC Me encantó la "V" en "VB", el diseñador visual fue literalmente lo mejor desde el pan rebanado.

Por supuesto, podrías hacer todo eso programáticamente, pero la magia de la "V" era tan atractiva que no podías evitar arrastrar ese botón. Nos animaron a tomar esa ruta.

Pero hace unos años, comencé a aprender sobre C # y el marco .net y me fascinó la forma en que todo lo que creía saber acababa de salir por la ventana. Hay mucha magia en VB6 que se revela completamente en .net: tome los constructores y el InitializeComponentsmétodo, por ejemplo. En este último, encontrará todas las instancias de control que ha arrastrado desde la caja de herramientas, todos los eventos que ha registrado y las propiedades que ha establecido en el diseñador.

Y eso está bien ... supongo. Es solo que siento que no soy "dueño" de lo que está sucediendo, este código que solo puedo modificar a través del diseñador me molesta muchísimo. Cada vez que copia un botón que dice "Ok" de un formulario a otro (a veces junto con su hermano "Cancelar"), en realidad está duplicando el código, y eso es un pecado, ¿no? SECO, no te repitas, dice el Papa .

Dejando de lado las religiones y las escuelas de pensamiento, con toda objetividad, ¿no deberíamos derivar formas de las formas básicas en su lugar, y tener el botón "Ok" (y todos sus amigos) vivir en la forma base? Algo así como FormBasede donde se deriva a DialogFormBase; todas las clases creadas en muy poco tiempo ... escribiendo código. Los botones se crean dependiendo de cómo se instancia la clase (es decir, un argumento enum constructor determina qué botones se crearán), los controles se colocan dentro de una disposición de paneles divididos y paneles de diseño de flujo, inyectados en el formulario comoContentque encaja en el panel de contenido principal. ¿No es esto lo que ASP.net hace con páginas maestras y marcadores de posición de contenido? Derivaría un formulario cuando necesito una nueva "página maestra", pero esta nueva "página maestra" aún se deriva de una clase de formulario base, por lo que las imágenes son consistentes en toda la aplicación.

Para mí, eso es mucho más reutilización de código que cualquier otra cosa que haya hecho con el diseñador en WinForms, y ni siquiera fue difícil, y el código no está abarrotado con un método de 200 líneas sobre el que no tengo control, puedo pon comentarios donde me gusta, un diseñador no los sobrescribirá. Supongo que es solo una cuestión de patrones y arquitectura, que es lo que me trajo a este enlace: el mejor diseño para formularios de Windows que compartirá una funcionalidad común , donde me di cuenta de que estaba en lo cierto, excepto la respuesta allí, sugiere exactamente lo que soy haciendo, pero está aconsejando contra la herencia de formularios debido a consideraciones de diseño. Esa es la parte que no entiendo .debido a consideraciones de estructura de código, especialmente en lo que respecta a la herencia de forma y control, que no veo ninguna razón para evitar, aparte de que rompe el diseñador .

No todos podemos ser flojos, entonces, ¿qué parte me estoy perdiendo?

Me opondré con un paradigma diferente: favorecer la composición sobre la herencia.

Incluso cuando comience a escribir código GUI a mano y use la herencia para compartir comportamientos y visuales entre formularios, encontrará el mismo problema que el diseño normal de OOP. Digamos que tiene DialogForm, que tiene botones Aceptar / Cancelar y GridForm, que tiene cuadrícula. Deriva todos los cuadros de diálogo de DialogForm y todos los formularios con Grid de GridForm. Y luego descubres que quieres forma con ambos. ¿Cómo lo resolverías? Si está utilizando la herencia de formularios, entonces no hay forma de resolverlo. Por otro lado, si está utilizando UserControls, simplemente puede poner GridControl en su formulario y listo. Y aún puede usar el diseñador con UserControls, por lo que no tiene que perder el tiempo escribiendo tedioso código GUI.

Gran parte de esto está vinculado a la pila de tecnología de elección.

WinForms y WPF pueden ser marcos de trabajo de interfaz de usuario de .NET, pero varían mucho en la forma de lograr el objetivo final. Ciertos paradigmas se mueven bien entre tecnologías, pero otros no, y no deberías intentar forzar un paradigma simplemente porque sientes que está destinado a existir en cada marco. Hay una razón por la que MVVM está orientado a WPF / SL y MVC es un concepto separado en ASP.NET de WebForms, etc. Ciertas tecnologías funcionan mejor con ciertos paradigmas.

Tenga en cuenta que el código generado generalmente debe eliminarse de sus preocupaciones DRY. Si bien es aplicable en algunos casos, la mayoría de las veces se debe ignorar. Los conceptos DRY sin duda deberían seguir siendo un foco fuera de su capa de Presentación, pero en la capa de Presentación, el código generado es a menudo un subproducto del marco en el que está trabajando. Esto no quiere decir que no pueda aplicar los principios DRY en su enfoque, sino que siga siendo cauteloso. ¿Podría crear un formulario base y heredarlo indefinidamente? Si. ¿Podría arrastrar y soltar componentes en un nuevo formulario cada vez que lo necesite? Si. Manténgase enfocado en el objetivo final, evitando posibles defectos, facilitando la refactorización aguas abajo y la escalabilidad mientras trabaja dentro de los límites de la pila de tecnología de elección.

Usted puede utilizar la herencia que le proporciona encapsular correctamente sus campos y rellenar en consecuencia. Si estuviera interesado en usar la herencia, mi sugerencia sería tener la forma base y un Modelo correspondiente para esa forma, y ​​para cada derivación derivar tanto la forma como el Modelo.

Una alternativa mucho mejor sería agrupar los controles relacionados en uno o más controles de UserControl. Solo necesita un poco de lógica para poner los datos relevantes en él.

Estoy totalmente de acuerdo con Mason Wheeler, aunque en tres años tal vez incluso él mismo había cambiado de opinión.

Estoy tratando de buscar alternativas para migrar desde los ejecutables de Delphi a la WEB.

Hasta ahora me decidí por UNIGUI, porque todavía puedo usar la herencia de formularios. Me gustaría que Delphi tuviera Mixins como Dart, ya que me permitiría tener menos antepasados. Pero siento que la gente escribe mucho más código en MVC que con la herencia de formularios visuales, ya que la mayoría de la navegación, llama a las reglas de validación en el módulo de datos (applyupdates), criterios de filtrado sql, buscando en el conjunto de datos del cliente, todo está escrito en 5 quizás 6 Forma antepasados.

Incluso el "Con MVC será más fácil para ti dejar a Delphi en la función" para mí no funciona como argumento, ya que la gente invitó a OOP, todo son clases, propiedades, métodos. Entonces, todo lo que necesito es un traductor. Realmente no pude encontrar ninguna ventaja, tal vez para sitios web que son mucho menos complicados pero cambian en una base diaria.