Las noticias entre lo agradablemente inesperado despertaron todo tipo de recuerdos, dulces y no tan. También recibí este artículo de ella, e inmediatamente me cansé de la nostalgia, y quise interpretar una elipsis tan pesada de ella en los últimos siete años.
Dephi fue una solución absolutamente brillante. Bueno, ya sabes, como los Beatles, como una interfaz gráfica de computadora con control del mouse, como un motor de combustión interna. La ingeniosa solución que ha llegado a nuestras vidas tan ampliamente que ni siquiera puede creer que alguna vez no estuvo allí, y dibujar ventanas, casillas de verificación y botones en Windows podría ser un verdadero dolor.
La parte ingeniosa, absolutamente, de Delphi fue VCL: el mismo conjunto de casillas de verificación y botones para las ventanas de Windows, que de repente se volvió tan fácil y simple arrastrar y soltar entre sí, y crear aplicaciones de Windows hermosas e inusuales.
Y como cualquier interfaz de usuario decente, esto funcionó, por supuesto, de acuerdo con el modelo de evento. OnClick en el objeto del botón describe todo lo que hace el botón, OnChange al ingresar en un campo de texto, todo es igual que en los adultos. Pero en lo sucesivo, además, desafortunadamente, todavía no había nada.
Nada de lo que sabemos ahora, quiero decir. MVC, por ejemplo: Delphi, considera que consistía en una V, luego todo quedó a merced del desarrollador. ¿Directamente desde OnClick para extraer una solicitud a la base de datos? Si por favor. En OnChange, abra un archivo e intente escribir en él, y si el archivo en su lugar no se bloquea silenciosamente con algo como Violación de acceso a la memoria, en cada paso (sin embargo, no tiene nada que ver con Delphi como plataforma).
Y debo decir que durante muchos años fue completamente feliz para todos, y algunos todavía están bastante contentos con eso. Los beneficios de una biblioteca delgada y hermosa de componentes de la interfaz de usuario son visibles de inmediato, los beneficios de cualquier controlador y modelo se hacen evidentes no en el primer año de desarrollo, ni en los primeros cien kilobytes de códigos fuente.
E incluso si se ha convertido, es fácil olvidarlo, hay una trampa mental aquí, como esas ilusiones ópticas y sonoras sobre las que se debate ferozmente en Internet. Así que déjame intentar lanzar un pequeño puente desde Delphi a una comprensión moderna de la interfaz de usuario y podemos descubrir qué sucede.
Entonces, la idea clave: separamos la presentación de los datos, el widget por separado, todo el trabajo con la información en él está separado. ¿Cuán separados? Digamos que el botón todavía tiene una inscripción y, a veces, un ícono. El usuario mismo puede introducir esta inscripción en el campo de texto y, a veces, el campo de texto tiene otra inscripción que explica al usuario qué es exactamente lo que conduce. Regla general: el widget se dedica a mostrar, al menos (SIC!) Logic, el que puede estar presente solo debe estar asociado con la pantalla y nada más. Digamos, si el botón no está listo para estirarse junto con la inscripción, la inscripción debe recortarse de alguna manera (por ejemplo, mostrar los puntos suspensivos y la versión completa en la información sobre herramientas), o dar un error al intentar establecer el valor más de lo que cabe (aunque esto la idea es regular, es probable que dicho error ya aparezca durante la ejecución del programa, en el momento más inoportuno).
Un campo de entrada de texto puede borrar las traducciones de carro del texto si es de una sola línea, pero no es necesario requerir, por ejemplo, ingresar solo números en él; este no es su trabajo. Así como el manejador de botones no necesita ninguna verificación, no se deben volver a dibujar las llamadas, el manejador de botones debe extraer el código externo, que ya es responsable de la lógica de la IU y de toda la aplicación.
Y si vives en un mundo nuevo y hermoso, mirando todo este alboroto de eventos de OOP, entonces el principio sigue siendo el mismo: presionar un botón cambia su estado al agregar la Acción correspondiente, y luego algo de código, el código no asociado con los elementos de la interfaz de usuario, mire esta acción, extraiga las conclusiones apropiadas y cambie el estado para que haya algo que mostrar en la interfaz de usuario.
Es decir, independientemente del entorno, la plataforma y el paradigma, los elementos visuales tienen un mínimo de funcionalidad y cero lógica en sí mismos. Reciben información en la forma más general, por lo que si tiene un TextBox, también es Input, también es un campo para ingresar texto, toma una cadena y le da una cadena. Y la tarea de convertir una línea en un número, el nombre de alguien o algo más astuto ya no es para el widget.
Bueno, entonces el Controlador o Presentador procesa el resultado y produce el resultado. Llámalo como estás acostumbrado, simplemente no coloques ningún elemento visual en él.
¿Cuál es el beneficio? Enumero en orden de lo más obvio a lo más, en mi opinión, lo esencial.
En primer lugar, la reutilización. Se puede pasar mucho tiempo entendiendo que un campo para ingresar una dirección postal, para ingresar un apellido y para ingresar una suma es, de hecho, el mismo campo. Uno y el mismo widget, con el mismo conjunto de características que se reduce a extraer un evento de entrada de texto o actualizar un estado. Y solo la lógica de trabajar con el texto dentro puede diferir. Un ejemplo de "cómo no hacerlo" de la vida: haga un campo para ingresar una suma de dinero (hasta dos decimales), y luego juegue durante mucho tiempo, rehaciéndolo para que a veces pueda ingresar una cantidad en el mismo campo (hasta 4 decimales) . Romper en el proceso todos los lugares donde se ingresa la cantidad en la solicitud, y repararlos de emergencia en medio de la noche. Esto a pesar del hecho de que, según la lógica de su trabajo, tenían diferencias en el tercer decimal. Puede escribir poemas sobre cómo los campos para ingresar direcciones de correo electrónico se convierten en campos para ingresar direcciones geográficas usando la herencia y las palabras de Dios.
En segundo lugar: la capacidad de prueba. También puedes probar la interfaz de usuario. Casi cualquier interfaz de usuario. Pero será costoso, en términos de tiempo y recursos gastados en el desarrollo de pruebas y en la ejecución de pruebas, y es poco probable que se inicien en cada reconstrucción, pero cuando las pruebas se bloqueen en el lanzamiento, esto será de fuerza mayor. Pero los componentes de la interfaz de usuario son los más riesgosos en términos de averías, se rompen, por regla general, con mayor frecuencia, con mayor claridad y dolor. Pero el código, arrancado de los widgets, está cubierto por pruebas unitarias. Y las pruebas unitarias son mucho más baratas: es más fácil de escribir, y puede ejecutarlas literalmente después de cualquier cambio, y siempre asegúrese de que nada se haya roto.
Y en tercer lugar, lo más importante, en mi opinión. Dibujar una parte de la interfaz de usuario junto con la lógica como una sola pieza es extremadamente difícil de derrotar a la pereza y pensar más profundamente cómo funciona. Para resolver escenarios, excepto idealmente positivos, cuando el usuario ingresó exactamente lo que se esperaba de él, hizo exactamente lo que se requería y recibió exactamente lo que quería. Ese mismo programador sagrado "todo funciona para mí".
La separación de la parte visual y la lógica te hace pensar, en primer lugar, cómo funciona la parte visual: qué entra, qué sale, qué sucede si algo que no se esperaba que entrara o saliera no funciona. Y escribir la lógica por separado del control lo obliga a escribirla en casos, es decir, de acuerdo con los posibles escenarios para usar una aplicación específica en un lugar en particular, incluidos los errores de procesamiento que surgen aquí y ayudar al usuario en las dificultades que experimenta aquí. Bueno, sí, no siempre, o más bien no en todo, una solución en general es mejor que una solución adaptada para un caso particular.
Para resumir. Puede escribir en Delph, o una aplicación para iOS, torturar la sufrida web por algún tipo de there-0, o remachar algún juego de microcontrolador en Python, si su código ha superado la fórmula "un molde, una consulta, un resultado" - Te diré Recomiendo separar decisivamente los widgets de cualquier lógica de su trabajo, y luego existe la posibilidad de que haya menos moscas en sus chuletas. Y a pesar de la no evidencia inicial perfecta de las ventajas de una solución de este tipo, cuanto más trabaje con ella, más de estas ventajas le aparecerán.