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.

CCP (Common closure principle)

Introducción

El principio Ccp, se basa en la premisa de que toda modificación que allí se realice exclusivamente deberá afectar al paquete sobre el cual se efectuara este proceso, más no todos los paquetes que se encuentren asociados a este.

LAS CLASES DE UN PAQUETE SE DEBEN CERRAR JUNTAS CONTRA LOS MISMOS TIPOS DE CAMBIOS QUE AFECTA A TODAS LAS CLASES DEL PAQUETE.

El objetivo principal de este principio más que la capacidad de reutilización es el mantenimiento ya que sus lineamientos proporcionan una capacidad de trabajar exclusivamente en la clase o paquetes afectados.

Desarrollo

Durante el periodo de desarrollo de una aplicación donde deberán intervenir múltiples clases y paquetes siempre se ha tratado de encontrar la manera para que la solución de una manera u otra se torne un tanto genérica, si ocurriera un cambio ¿te gustaría que fuera dentro de un paquete o a través de muchos?, se preferirá buscar en un solo paquete y realizar su modificación ya que gran cantidad de los otros componentes no dependen de esta parte provocando un acoplamiento con los demás que ir verificando todos los lugares posibles donde haya que realizar esta modificación ya que se tendría que tener recursos adicionales tales como tiempo, esfuerzo y posiblemente estos cambios masivos generen cambios en la estructura fundamental del proyecto.

El CCP es un intentos por reunir en un solo sitio todas y cada una de las clases que a través del ciclo de vida de nuestro proyecto puedan variar, sin importar que las clases se vinculen física o conceptualmente, de esta manera se produce mayor efectividad al momento de realizar modificaciones, agregaciones, liberaciones, validaciones y redistribución del software

Este principio está relacionado con el OCP (cerrado abierto), el cual se basa en la premisa de que las clases deberán estar cerradas para la modificación y abiertas para la extensión, aunque el cierre no se podrá realizar en un 100%, de esta manera se deberá realizar una planeación estratégica para proveer el menor impacto de modificación posible

Y luego en cierta manera se derivara el PCC el cual agrupa las clases que no pueden cerrarse contra modificaciones así restringiendo cambios a la mayor brevedad posible

EJEMPLO

Un ejemplo que se puede observar está en la utilización de varios paquetes los cuales son habitualmente usados en los distintos software, la clase java.io es una de ellas, este paquete de entrada y salida contiene las clases de acceso a ficheros de filtrado, serializarían de objetos etc. FileInputStream, FileOutputStream, FileReader, FileWriter. También contiene los interfaces que facilitan la utilización de las clases: DataInput, DataOutput, Externalizable, FileFilter, FilenameFilter, ObjectInput, ObjectOutput, Serializable.

...