Simplifica tu código Delphi...

[[movorack]]

Tomado de aquí

Simplifica tu código, piensa en clases, abstrae y racionaliza, usa el sentido común, etc… son algunos de los lemas que hemos podido compartir durante muchos de los artículos anteriores, casi desde siempre, con mas o menos acierto. Valga la redundancia, casi diría que en realidad, es una preocupación cuasi universal que nos corroe, a medida que avanzamos y aprendemos y nos formamos. También de alguna forma, exteriorizamos esos pensamientos en muchos de los post que acabamos publicando.
Nuestro punto de parada hoy, es nuevamente el blog de Stefaan Lessage, y la parada es para compartir cuatro artículos que ha escrito durante el mes de marzo y que pienso que forman parte de esa idea general que siempre hemos intentado plasmar: pensar en clases y abstraer. Pienso que la lectura de las cuatro entradas de Stefaan es muy aconsejable y si bien, puede resultarnos mas o menos incomodo que esté escrita en otro idioma (ese punto ya depende de cada uno), existe el suficiente código para que pueda entenderse el trasfondo y la enseñanza que aporta. Sobretodo, os la aconsejo si os estáis iniciando en el entorno y buscais patrones de razonamiento que os sirvan de referencia en vuestros desarrollos.
La serie se titula, como no, “Simplify your Delphi Code using some basic rules, OO techniques and some refactoring“. Mas o menos, “Simplifica tu codigo Delphi usando algunas reglas básicas, tecnicas orientadas a objetos y refactorización”.


Parte 1
En la primera parte de la serie, Stefaan Lessage presenta el problema o la cuestión. Es un capítulo introductorio y breve, en el que inicia su reflexión imaginando una necesidad que suele darse con frecuencia y que consiste en retomar código escrito años atrás para su revisión. Puede que nos toque enfrentarnos a código difícil de leer o entender y que requiera un nuevo enfoque para facilitar en un futuro su mantenimiento.
Al hilo de mostrarnos las ventajas, Stefaan se centra con un ejemplo que puede ser representativo de esa ganancia y que va a servir de eje sobre el que van a girar el resto de los artículos de la serie. Personalmente, creo que ha elegido un ejemplo que recoge una necesidad básica en cualquier aplicación: guardar y cargar datos de personalización. Y como imagináis, casi siempre van a estar implicados o bien archivos ini o el registro, ficheros xml, etc.


Parte 2
La segunda parte, una vez planteada esa introducción, se nos muestra algo de código. Código que podría representar a esas lineas que deberíamos revisar, bajo un nuevo enfoque al hilo de la programación orientada a objetos. Siguiendo con su ejemplo, muestra varios procedimientos que permitirían desde los eventos de creación y destrucción del formulario, cargar y guardar los valores de personalización. Lógicamente, junto con estas lineas de código se nos presentan las desventajas de estas decisiones y los problemas que pueden suponer en distintos escenarios.


Parte 3
Aquí ya entra Estefaan Lessage en el primer acercamiento a resolver el problema desde la perspectiva OOP. Para ello, crea una clase base que permita tratar distintos tipos de datos de forma unificada. Así pues, la clase TdvSetting realmente no hace nada mas que preparar el camino. De hecho, los metodos Get/Set se limitan unicamente a generar una excepción, puesto que ella no sabe realmente como debe responder a dichos métodos. Será sus descendientes los que sobrescriban los métodos adecuados al contexto de la aplicación, creando código especifico.


Parte 4
Y ya la parte cuarta, finaliza la serie. En este artículo se define la clase TdvStringSetting a modo de ejemplo, descendiente de TdvSetting, y se nos proponen nuevas clases descendientes (TdvInteggerSetting, TdvBooleanSetting, etc.) y una clase adicional TdvSettings, descendiente de TObjectList, al modo de contenedor. Fijaros en un detalle importante, esta lista de objetos, recibe como parámetros en su funciones y procedimientos la clase base, jugando de esa forma Steffaan Lessage con la herencia y el polimorfismo (si no recuerdo mal a este tipo de polimorfismo se denomina como Polimorfismo de subtipado o de inclusión).

Creo que vale la pena que perdáis unos minutos y reviséis el código ya que este tipo de razonamientos pueden aportar un valor añadido al código que escribimos. No es tan importante la cantidad de lineas que uno puede abarcar en una jornada frente a que éstas garanticen que pueda ser revisadas meses después al aire de un nuevo contexto o en respuesta de nuevos requerimientos. Calidad o cantidad… Siempre debemos “aspirar” a la calidad.
Comparto plenamente lo escrito por Stefaan en la introducción

Think before you start writing your first line of code…

Una verdad como un templo.