Principios y Patrones de Diseño



Descargar 227,42 Kb.
Página1/3
Fecha de conversión08.06.2017
Tamaño227,42 Kb.
  1   2   3



Principios y Patrones de Diseño

Traducción y resumen del artículo de Robert C. Martin www.objectmentor.com





  • Arquitectura de software

  • Dominio de patrones de diseño: módulos y su interconexión



Introducción al concepto de arquitectura orientada a objetos definida como la estructura de clases y paquetes que permiten mantener una aplicación de software flexible, robusto y desarrollable.
Se presentan principios y patrones que respaldan dicha arquitectura y que han demostrado ser a lo largo del tiempo una poderosa ayuda dentro de la arquitectura de software.

Copyright © 2000 by Robert C. Martin. All Rights Reserved

El diseño de muchas aplicaciones de software comienza como una imagen vital en la mente de sus diseñadores.
Síntomas de la degradación desde dentro hacia fuera del diseño
Rigidez: tendencia del software a ser difícil de cambiar.

Lo que comienza como una deficiencia de diseño termina siendo una gestión de política negativa.
Fragilidad: tendencia del software a quebrarse en muchos lugares cada vez que cambia.

Tal software causa la sospecha de administradores y consumidores de que los desarrolladores han perdido control de su software. Reina la desconfianza y se pierde la credibilidad.
Inmovilidad: inhabilidad de reusar software.
Viscosidad: cuando los métodos de preservar el diseño son más difíciles de emplear que los hacks, la viscosidad del diseño es elevada.

Enfrentados a un cambio, los ingenieros usualmente encuentran más de una forma de realizarlo.
Los requerimientos van cambiando en formas que el diseño original no anticipaba. Debemos encontrar alguna manera de que nuestros diseños sean resistentes a tales cambios y protegerlos de la degradación desde dentro hacia fuera.
En orden de prevenir la degradación de la arquitectura de dependencia, las dependencias entre módulos en una aplicación deben ser manejadas mediante la creación de firewalls de dependencias.


Principios de Diseño de Clases Orientadas a Objetos
The Open Closed Principle (OCP)

Un módulo debe ser abierto para extensión pero cerrado para modificación.


La abstracción es la clave para el OCP.

Técnicas: Polimorfismo dinámico – Polimorfismo estático



Siempre es mejor que los cambios no se propaguen dentro de código existente que ya funciona. Si no tienes que cambiar código funcionando no es probable que lo rompas.
The Liskov Substitution Principle (LSP)

Las subclases deben ser sustitutas de sus clases base.


Un usuario de una clase base debe continuar funcionando correctamente si se le pasa una instancia de una clase extendida.

Para poder llevar a cabo la sustitución, el contrato de la clase base debe ser honrado por la clase extendida.

  • Precondiciones menos fuertes que la de los métodos de la clase base.

  • Poscondiciones menos débiles que la de los métodos de la clase base.

Los métodos extendidos deben esperar no más y proveer no menos.

Violaciones del LSP son violaciones latentes del OCP.
The Dependency Inversion Principle (DIP)

Dependa de abstracciones. No dependa de implementaciones.


Los módulos de alto nivel tratan con las políticas de alto nivel de la aplicación. A estas políticas generalmente no le interesan los detalles de sus implementaciones. Luego, ¿por qué los módulos de alto nivel deberían depender directamente de los módulos de implementación?

Las abstracciones son puntos de articulación; representan los lugares donde el diseño puede doblar o ser extendido, sin modificarse ellas mismas.
Cualquier cosa concreta es volátil. La no volatilidad no es un reemplazo para la capacidad de sustitución de una interfase abstracta.
The Interface Segregation Principle (ISP)

Muchas interfases específicas para clientes son mejores que una sola interfase de propósito general.


Los clientes deben ser categorizados por su tipo y se deben crear interfases para cada tipo.
Cuando las aplicaciones orientadas a objetos se mantienen, las interfases a las clases existentes y componentes generalmente cambian. Este impacto puede ser mitigado agregando nuevas interfases a objetos existentes en vez de cambiar las interfaces que ya existen.
Como con todos los principios, se debe cuidar de no exagerar en su uso.

Principios de Arquitectura de Paquetes
Las clases son un medio necesario pero insuficiente de organizar un diseño. La mayor granularidad de los paquetes ayuda a mantener el orden.


  • Principios de Cohesión de Paquetes


The Release Reuse Equivalency Principle (REP)

El gránulo del reuso es el gránulo del lanzamiento.


Un elemento reusable, sea un componente, una clase o un grupo de clases, no puede ser reusado a menos que este vinculado a un sistema de lanzamiento de algún tipo. Ya que los paquetes son la unidad de lanzamiento, también son la unidad del reuso.
The Common Closure Principle (CCP)

Clases que cambian juntas, pertenecen al mismo grupo.


Un gran proyecto de desarrollo está subdividido en una extensa red de paquetes interrelacionados. Se pretende minimizar el número de paquetes que cambian en cada ciclo de lanzamiento del producto.
The Common Reuse Principle (CRP)

Clases que no son reusadas conjuntamente, no deben ser agrupadas.


Si esto sucede, los cambios a una clase sin relevancia igualmente forzarían un nuevo lanzamiento del paquete, provocando el esfuerzo necesario para su mejora y revalidación.



The Acyclic Dependencies Principle (ADP)

Las dependencias entre paquetes no deben formar ciclos.


Los ciclos se pueden romper de dos maneras. La primera involucra la creación de un nuevo paquete, mientras que la segunda hace uso del DIP y el SIP.
The Stable Dependencies Principle (SDP)

Establezca la dependencia en la dirección de estabilidad.


La estabilidad está relacionada con la cantidad de trabajo necesario para realizar un cambio.
Medida de Estabilidad

Aferente de acoplamiento. El número de clases fuera del paquete que depende de clases dentro del mismo.

Eferente de acoplamiento. El número de clases fuera del paquete que dependen las clases dentro del mismo.

Inestabilidad. Medida en el rango [0,1]



Dependa de paquetes cuya medida de inestabilidad sea menor a la suya.
  1   2   3


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal