Estrategias de la Arquitectura del Software

El proceso de construcción y desarrollo del software demanda una serie de estrategias específicas. Estas estrategias se pueden entender como algo más que buenas prácticas. Se trata en breve de una serie de reglas fuertemente basadas en la experiencia. A modo groso, una estrategia podría consistir en escribir código robusto, escueto y potente. Entre otras cosas, hacer énfasis en las repitencias de procesos, etc. Las estrategias pueden ser prácticamente infinitas. A continuación, describiremos algunas de ellas para poder conocer bien de cerca algunas de sus virtudes.

Estrategia DRY

La estrategia DRY (Don’t Repeat Yourself) “No Repitas las Cosas”, en breve se trata de una estrategia que nos ayuda a evitar la repitencia de código. El eje fundamental de esta estrategia es la de crear un código único para su uso y por supuesto, la gran posibilidad de reutilizarlo cuando sea oportuno. Dicho de modo gracioso, es una suerte de “guerra contra el copy & paste”. 

Un buen ejemplo de ello son el uso de las clases. Usted crea una librería más o menos elaborada, la que debe cumplir un rol específico en su código. Una mala práctica sería que su código, se repita y se desperdigue por todo el contexto de su aplicación. En lugar de ello, a través de su clase creada, usted acude a la reutilización evitando la repitencia mediante las técnicas de herencias o instancias de clases. En breve, su clase es escrita por única vez y luego consumida por el resto de los diversos módulos de la aplicación.

Estrategia SRP

La estrategia SRP (Simple Responsibility Principle) “Principio de Responsabilidad Simple”, hace énfasis en las responsabilidades de los módulos intervinientes en un contexto de una aplicación. La idea de fondo es crear una responsabilidad única para cada módulo. Un uso colectivo de dichos procesos tienden a desnaturalizar las responsabilidades. Ello quiere decir que el destino de un proceso, no queda muy claro en el contexto de las operaciones. Existe una suerte de difusión de procesos o una multiplicidad de responsabilidades que desnaturalizan la interpretación de los procesos.

Un buen ejemplo de ello es la construcción de una librería que contribuye a resolver un código de barras. Mientras que esta librería es utilizada para cumplir el rol destinado, se cumple la regla. La regla dejará de tener efecto cuando esta librería se la utilice para realizar una tarea que difiere de su origen. Imagine que esta librería se utilizara para generar un código aleatorio para otro destino que no sea el código de barra. Si bien podría ser una solución interesante, de fondo rompe la regla SRP. Por tanto, este tipo de prácticas deben ser evitadas en lo posible si pretendemos ser coherentes con los estándares, la arquitectura y las buenas prácticas.

Estrategia OCP

La estrategia OCP (Open Closed Principle) “Principio Abierto Cerrado”, se basa en el proceso de evitar las modificaciones y aceptar las extensibilidades. La idea de fondo es hacer énfasis fuertemente en la extensión de los desarrollos y evitar los cambios originales. Pongamos un ejemplo para que se pueda comprender mejor.

Durante la fase de desarrollo de librerías de clases en una aplicación, se debe considerar varios factores. Por empezar, las clases primarias deben ser genéricas o muy básicas para luego, a medida de que se vayan extendiendo, se vayan especificando. Sin embargo, el desarrollo de esta escalabilidad, demanda evitar cambios en los procesos originales. El desarrollo de esta estrategia, debería considerar que las bases del proceso de escala, no deben cambiar dado que los cambios, podrían crear un efecto avalancha sobre las extensibilidades, convirtiéndolo en inestable y poco seguro. Por tanto, un buen diseño que prevee la extensibilidad, debe plantearse muy seriamente este proceso primordial para evitar malas prácticas y romper la regla OCP.

Estrategia LSP

La estrategia LSP (Liskov Substitution Principle) “Principio de Substitución de Liskov”, hace énfasis en los subtipos puesto que cada clase que hereda de otra, puede usarse como su base, sin la necesidad de conocer sus diferencias entre estas. Veamos un ejemplo para comprender mejor.

Un ejemplo lo podemos encontrar en el uso de las interfaces donde son implementadas en una clase hija y que luego, dentro del contexto de la misma, se pueden sobrescribir para que cumplan su rol destinado específico, sin tener que alterar las interfaces primarias.

Estrategia IOC

La estrategia IOC (Inversion Of Control) “Inversión de Control”, se trata de un proceso de inversión del flujo de control con respecto y en comparación con el proceso de programación procedural. También es conocido con el término convencional de “Delegando Responsabilidades”. Se puede entender rápidamente como que una parte de la programación procedural que utiliza o consume otra parte del código que se encuentra dentro del control del proceso.

Un ejemplo muy cercano a estos procesos son los Framework. En el caso de los desarrolladores de Framework .NET, contamos con varias soluciones que hacen uso intensivo de estos procesos y que gestionan los ciclos de vida. Por ejemplo, en el caso de los formularios de Windows “WinForms”, el uso de eventos que gestionan los procesos en el contexto de los formularios o el modelo MVC, cuando son orientados a los servicios o páginas Webs, donde a través de los helpers de MVC, se obtienen diversos procesos autogestionados.

Estrategia DIP

La estrategia DIP (Dependency Injection Principle) “Principio de Inyección de Dependencias” o DI (Dependency Injection) “Inyección de Dependencias”, a modo groso podemos decir que se encarga de “inyectar” componentes a las clases que tenemos implementadas.

Las clases son dependientes del proceso para poder funcionar correctamente. El proceso no permitirá que nuestras clases creen las condiciones para cumplir sus roles sino que serán proporcionadas desde otras clases contenendoras, obviamente pertenecientes al mismo Framework de inyección de dependencias. Estas inyectarán la implementación deseada en nuestro contrato, es decir en nuestras clases, sin la necesidad de requerir de los procesos de la palabra clave new, que dicho del paso, es utilizada para crear instancias de objetos de clases.

Para concluir, no confundir DIP o DI con IOC. Si bien los procesos pueden en algunas ocasiones aparentar ser similares, existe una diferencia de fondo muy importante. La confusión que surgen entre ambos radica en el contexto de uso para algunas soluciones, que aparentan realizar operaciones similares aunque ambas estrategias, resultan ser totalmente diferentes.

Estrategia COC

La estrategia COC (Convention Over Configuration) “Convención Sobre Configuración”, se centra en el proceso de diseño y consiste en la declaración de una serie de convenciones que permiten asumir el proceso de configuración de un sistema por defecto.

Estrategia ISP

La estrategia ISP (Interface Segregation Principle) “Principio de Segregación de Interface”, se puede comprender muy fácilmente cuando una clase A que tiene una dependencia con la clase B, no debería depender de los métodos de la clase B que no vaya a usar nunca. En breve, los diversos recursos de una clase, no deben depender si o si de tener que ser utilizados pese a no utilizarlos en otros propósitos. Esto podría verse muy a menudo en aquellos casos donde se hace un uso abusivo de clases abstractas, aquellas que deben implementar si o si todos sus recursos y peor aún, que terminen por depender de todos ellos. Esto en consecuencia, rompería la regla de ISP.

Resumen

Las diversas estrategias permiten desarrollar y crear software de altas prestaciones, normalizado, escalable, sólido y seguro. Las diversas estrategias que plantean la mayoría de los Framework, resultan ser muy convenientes porque presentan muchísimas ventajas. Cuando se construye el software, el factor de coherencia más la debida aplicación de las estrategias, nos conducirán por las buenas prácticas más aún, a contribuir a desarrollar sistemas robustos. La gran base de todo esto es en esencia la de satisfacer los principios de la Ingeniería del Software. Por ejemplo, cuando se hace uso de los patrones como el MVC (Model View Controller) “Modelo Vista Controlador”, estamos proporcionando un modo deserrallo y constructivo del software que facilita la escala, lo convierte en ágil y máxime aún, permite que los desarrollos y diseños resulten ser mucho más fluídos y eficaces.

Por tanto y para ir cerrando estos conceptos, resulta primordial considerar todos estos análisis estratégicos, si deseamos obtener los mejores resultados. Siguiendo esta línea coherentemente, los resultados que obtendremos serán extraordinarios.