Principios

PRINCIPIOS DE DISEÑO

Se desarrollan y publican hace ya una década por Robert Martin “Tio Bob”, se dice que la mayoría usamos lenguajes orientados a objetos, por este motivo surgen patrones de diseño. Aplicar estos principios nos ayudaran a crear un código más legible, simple, reusable, más fácil de mantener. Por eso a través de este documento conoceremos los siguientes principios:

CONTENIDO

PRINCIPIOS DE DISEÑO………………………………………………………………………………………………….1

REP (Release Equivalence Principle)……………………………………………………………………………….3

CCP (Common closure principle)…………………………………………………………………………………….5

DIP (Dependency Inversion Principle)…………………………………………………………………………….7

CRP (The Common Reuse Principle)……………………………………………………………………………….9

ADP (Acyclic Dependencies Principle)………………………………………………………………………….11

SDP (Stable Dependencies Principle)……………………………………………………………………………14

SAP (Stable Abstractions Principle).……………………………………………………………………………..17

SRP (Single Responsability Principle)…………………………………………………………………………...21

OCP (Open/Closed Principle)……………………………………………………………………………………….25

LSP (Liskov Sustitutation Principle)……….……………………………………………………………………32

ISP (Interface Segregation Principle)……….…………………………………………………………………..33

 REP (Release Equivalence Principle)

El principio de reutilización de principio de equivalencia hace referencia a la creación de paquetes con clases reutilizables.

Descripción del principio de paquetes REP:

Para entender la esencia de este principio, es necesario mencionar que reutiliza no es copiar y pegar. Reusar código tampoco es en esencia adjuntar librerías de terceros a las propias, esto se basa en el argumento de que si hay errores deben ser corregidos y si esos errores los corrigen terceros se debe adaptar el código correspondiente.

Entonces podemos decir que reutiliza código sin tener que acceder al código fuente. En el momento que haya nuevas versiones de dicho software solamente es necesario adaptar el código a la versión y acoplarlo al proyecto en el momento adecuado.

El REP establece que el grado de reuso no puede ser inferior al grado de reléase, esto quiere decir que para reusar código no se debe trabajar con un reléase desactualizado.

Ejemplo de aplicación del Principio de Equivalencia reutilización / Release (REP):

Supongamos que existe una aplicación de pagos, ahora necesitamos saber que partes de dicha aplicación vamos a reutilizar.

Cuando otra división de la empresa u otra empresa requiera utilizar el mismo sistema pero con un conjunto de políticas diferentes, no puede volver a utilizar clasificaciones, horarios, afiliaciones, etc. Pero si podría reutilizar las funcionalidades  de PayrollDomain, PayrollApplication, Solicitud, PayrollDatabase, ahora supongamos que la misma empresa que desarrollo el sistema de pagos, requiere escribir un software de análisis de la base de datos y reutilizara las funcionalidades PayrollDomain, clasificaciones, métodos, horarios, afiliaciones, PayrollDatabase  y PDImplementation.

En ambos casos el granulo de reuso o reutilización es un componente.

Lo que quiero representar con este ejemplo es que rara vez, o nunca, se reutiliza una sola clase de un componente. La razón es simple: Las clases dentro de un componente deben tener coherencia. Es decir, que dependen unas de otras y no pueden ser separadas tan fácilmente. No tendría ningún sentido, por ejemplo, utilizar la clase Empleado sin utilizar la clase PaymentMethod. De hecho, con el fin de hacerlo, tendría que modificar la clase de empleado para que no contenga una instancia PaymentMethod. Desde luego, no queremos apoyar el tipo de reutilización que nos obliga a modificar los componentes reutilizados. Por lo tanto, el gránulo de la reutilización es el componente. 

CONCLUSIONES

• El reuso se debe realizar a nivel de componentes.
• El reuso no debe obligar a modificar los componentes reutilizados.
• El reuso no exige ingresar al código fuente

HISTORIA DE LOS PRINCIPIOS SOLID

A lo largo de la existencia de la programación, las personas que han tratado de resolver los problemas cotidianos se han enfrentado a varios problemas como:

¿Cómo realizar este proyecto?

¿Cómo modelar la situación?

O cuando nos enfrentamos a la codificación de diseños mal realizados, los principios fueron creados como reglas bases para encaminar el diseño de soluciones a modelos productivos que no sean rígidos, frágiles o inmóviles, se trata de crear modelos que resuman varias situaciones en una sola para así encapsular la mayor cantidad de problemas darle su solución pero a la vez sea tan flexible como para adaptarse a otro problema.

...