martes, 31 de diciembre de 2019

Capítulo 5: Programación orientada a objetos - Clean Architecture


La programación orientada a objetos tiene muchas definiciones aunque su propósito es modelar el mundo real a través de conceptos como la encapsulación, herencia y poliformismo.

Encapsulación

Es un mecanismo para agrupar datos de un mismo concepto y funciones que operan sobre estos datos. La encapsulación también brinda la oportunidad de ocultar la implementación de manera que sólo se puede interactuar con los datos a través de los método que son públicos. La agrupación de los datos y las funcionalidades sobre los mismo se definen en clases.

Herencia

Es otro mecanismo cuya finalidad es extender la funcionalidad de una clase. Una clase que hereda de otra adquiere los datos y funciones de la clase de la que extiende. Esto conlleva a la reutilización de código.

Poliformismo

El poliformismo es el tercer mecanismo y establece que, a través de una interfaz, es posible definir un comportamiento. Los comportamientos vienen definidos por las funciones que operan sobre los datos. Cualquier clase puede incorporar un comportamiento establecido, a través de una interfaz, y es responsabilidad de cada clase el implementar el mismo.

Gracias a este mecanismo, distintas clases que incorporan el mismo comportamiento y, a pesar de que tengan implementaciones distintas, se puedan intercambiar para un mismo propósito.

Esto lleva a que cualquier clase A que tenga una dependencia con otra clase B que incorpore un comportamiento Z pueda invertir esa dependencia. Eso significa que un objeto de la clase A ya no cree una instancia del objeto de la clase B en su interior si no que se utilice a través de alguno de sus método un objeto que tenga un comportamiento Z. De esta manera se “inyecta” la dependencia.

Gracias a la inyección de dependencias los programadores tienen el control absoluto sobre todas las dependencias del sistema. Con esto se puede conseguir que las reglas de negocio sean independientes, no tengan dependencias, de la base de datos o el framework con el que se trabaje.

Conclusión

La programación orientada a objetos es la habilidad de usar el poliformismo para ganar el control absoluto de todas las dependencias del sistema. Esto permite al arquitecto a crear una arquitectura de plugins en la cual los módulos que contienen las políticas de alto nivel son independientes de las reglas de bajo nivel.

Los detalles de bajo nivel son relegados a plugins que se pueden desarrollar y desplegar de manera independiente de los módulos de la política de alto nivel.


lunes, 30 de diciembre de 2019

Capítulo 3: paradigmas - Clean Architecture


Actualmente hay 3 paradigmas de programación:

  • Programación estructurada: impone disciplina en la transferencia directa de control.
  • Programación orientada a objetos: impone disciplina en la transferencia indirecta de control.
  • Programación funcional: impone disciplina en la asignación.

Estos tres paradigmas coinciden con los tres grandes aspectos de la arquitectura: funcionalidad, separación de componentes y administración de los datos.

sábado, 28 de diciembre de 2019

Capítulo 2: una historia de dos valores - Clean Architecture


Un sistema software provee dos valores: el comportamiento y la estructura.
Comportamiento
El comportamiento hace referencia a las funcionalidades del sistema, es el QUÉ debe hacer. Muchos programadores, y no programadores, creen que el trabajo consiste en desarrollar esas funcionalidades y arreglar los bugs que van surgiendo. Esto no es verdad.
Estructura
La estructura hace referencia al CÓMO está implementado el comportamiento. El CÓMO estará formado por una serie de componentes y su interacción entre ellos. A esta estructura se le denomina arquitectura del sistema.

Cuando hay que desarrollar una nueva funcionalidad, esta se suele desarrollar y dar como resultado una implementación concreta. Si la arquitectura es dependiente de implementaciones concretas, cada vez será más complicado el añadir componentes y que estos interactúen entre ellos. Por esta razón, las arquitectura deberían ser «agnósticas» en cuanto a implementaciones concretas.
¿Qué es más importante?
El valor de un sistema viene determinado por la utilidad del mismo:

  • Si el sistema tiene el comportamiento esperado pero una mala arquitectura a la larga se incrementará la dificultad de añadir nuevos comportamientos hasta el punto de que los costes serán tan altos que harán inútil el sistema.
  • Si un sistema no tiene el comportamiento esperado pero tiene una buena arquitectura no será difícil añadir el nuevo comportamiento por lo que el sistema continuará siendo útil.
La matriz de Eisenhower
Según el 34 presidente de los Estados Unidos Dwight D. Eisenhower:

«I have two kinds of problems, the urgent and the important. The urgent are not important,  and the important are never urgent.»
Matriz de Eisenhower

Importante
Urgente
Importante
No urgente
No importante
Urgente
No importante
No urgente

La matriz establece que los problemas que son urgentes son raramente importantes mientras que las cosas importantes son raramente urgentes. 

Estos cuatro casos se pueden ordenar con prioridad siendo esta:

  1. Importante y urgente.
  2. Importante pero no urgente.
  3. Urgente pero no importante.
  4. Ni urgente ni importante.

Con esta tipología de problemas podemos concretar que:

  • El comportamiento es algo urgente pero no es particularmente importante.
  • La arquitectura del sistema es algo importante pero no es algo particularmente urgente.

Según la lista de prioridades, la arquitectura de un sistema ocupa los puestos 1 y 2 mientras que la funcionalidad ocupa los puestos 1 y 3.

La evaluación de las tareas dependen de la capacidad del administrador para evaluar las mismas y si este es consciente de la importancia de la arquitectura. Incluso aún teniendo el criterio suficiente, la presión por parte de factores externos que quieren ver el comportamiento hacen que el administrador tome tareas urgentes pero no importantes pasan a ser importantes y urgentes.

La responsabilidad del equipo de desarrollo es la de afirmar la importancia de la arquitectura sobre la urgencia de las funcionalidades. Esta es la razón por la que no deben ceder a presiones externas de manera que que el sistema que se cree sea fácil de mantener a la par de implementar nuevas funcionalidades.

viernes, 27 de diciembre de 2019

Capítulo 1: Qué es el diseño y qué es arquitectura - Clean Architecture


Cuando surge la necesidad de desarrollar un nuevo sistema software hay una primera fase que define el QUÉ se quiere hacer, esta fase debería (aunque extrañamente no siempre así) proporcionar una especificación de lo que el sistema debería hacer.

Una vez que está definido el QUÉ debe hacer el sistema comienza una segunda fase para ver CÓMO se va a abordar el desarrollo del sistema.

En este punto, el desarrollo de sistema va a tener una parte que modele el QUÈ hay que hacer (las reglas de negocio) y otra parte que tendrá más que ver con qué tecnologías se van a utilizar para llevarlo a cabo.

Por ejemplo, si el nuevo sistema software consiste en el juego de las tres en raya las reglas del negocio sería las reglas del juego (alto nivel) mientras que las tecnologías que se van a usar las cuales podrían comprender un entorno LAMP, MEAN, etc. (bajo nivel)

La arquitectura tiene que ver más con las partes de alto nivel mientra que el diseño tiene que ver más con las partes de bajo nivel. No obstante, no hay una línea clara entre los dos conceptos.
La meta
Según Robert. C. Martin la meta de un buen software es:

«The goal of software architecture is to minimize the human resources required to build and
Maintain the required system.»

La calidad del diseño va a venir determinada por el tipo de esfuerzo durante el tiempo de vida del sistema. Si el esfuerzo se mantiene el diseño tiende a ser bueno mientras que si el esfuerzo se incrementa con cada nueva versión el diseño es malo.