Principios de diseño orientado a objetos

Gabriel Guerrero Martínez

Universidad Distrital Francisco José de Caldas
Facultad de Ingeniería
Bogotá, Colombia
20142005115

I. Introducción un único motivo para que cada clase sea modificada.

Los principios de diseño son un conjunto de diseños El efecto que produce este principio son clases con nombres
y buenas prácticas que se emplean en DOO y POO muy descriptivos y por tanto largos, que tienen menos
(diseño y programación orientada a objetos). Aplicar estos de cinco métodos, cada uno también con nombres que
principios nos ayudaran, entre otras cosas, a crear un sirven perfectamente de documentación, es decir, de varias
código que sea más legible, simple, reusable, escalable, palabras: CalcularAreaRectangulo y que no contienen más
mas fácil de mantener, es decir, nos ayudaran a evitar los de 15 líneas de código.
problemas con los que nos solemos encontrar a medida
que nuestro código va creciendo.
II. Principio S.O.L.I.D.
En el año 1995 Robert C. Martin decidió nombrar y
resaltar algunos principios de diseño orientado a objetos, 5
principios fundamentales que hablan del diseño orientado
a objetos en términos de la gestión de dependencias. Las
dependencias entre unas clases y otras son las que hacen
al código más frágil o más robusto y reutilizable. El
problema con el modelado tradicional es que no se ocupa
en profundidad de la gestión de dependencias entre clases
sino de la conceptualización.

Fig. 2. Ejemplo Responsabilidad única

B. (OCP) Open-Closed Principle

Este principio dice que una entidad software debe estar
destinada para ser ampliada mas no para ser modificada,
ya que unas entidades de este dependerán directamente
de otras y si se permite la modificación se verá afectado
causando daños en cascada.

Para evitar estos daños colaterales se debe permitir

que el comportamiento de una entidad sea modificado sin
alterar su código fuente, si se desea lograr esto se podría
crear una clase padre de tipo abstracta a la cual por medio
de herencia y redefinición de los métodos se puede cambiar
el comportamiento mas no el código fuente.
Fig. 1. Principios SOLID

A. (SRP) Single Responsibility Principle

Este es el principio que da origen a la S y dice que cada
clase deberá ocuparse de una sola acción, es decir habrá
 Fig. 3. Ejemplo open/close

C. (LSP)Liskov substitution principle

Este principio fue definido por Barbara Liskov. Dice
que cada clase que hereda de otra puede usarse como su
padre sin necesidad de conocer las diferencias entre ellas,
los objetos deberan ser reemplazados por ejemplos de su
subtipo esto sin que la funcionalidad del sistema desde
el punto de vista de los clientes se vea afectada. Por
ejemplo si A es un subtipo de B, entonces los objetos de
tipo A pueden sustituir objetos de tipo B. Fig. 5. Ejemplo Segregación de Interfaces

E. (DIP) Dependency Inversión Principle

Fig. 4. Ejemplo Sustitución de Liskov
Este principio confirma que las abstracciones están
conectadas y ayuda a conseguir un código que es fácil de
reutilizar y con una jerarquía de clases fácil de entender.
Ademas tiene una fuerte relación con open-close. Robert
c Martin incluso dijo que “una violación de LSP es una
violación latente de OCP”.
D. (ISP) Interface Segregation Principle
Este principio establece que el usuario del programa
solo tendrán conocimiento de los métodos que realmente
usaran y no de todos que en última instancia no son
utilizados, este principio se aplica sobre una ampliar
interface donde se segmentara en pequeñas interfaces más
específicas que contendrán lo que cada usuario necesite
pudiendo ignorar el resto, llamado esto como “ interfaces
de rol”.
Este principio explica como un módulo concreto A,
no debe depender directamente de otro módulo concreto
B, sino de una abstracción de B. Tal abstracción es una
interfaz o una clase (que podría ser abstracta) que sirve
de base para un conjunto de clases hijas.
Al seguir este principio, las relaciones de dependencia
convencionales establecidas desde los módulos de alto
nivel de establecimiento de políticas a los módulos de
dependencia de bajo nivel se invierten, lo que hace que
los módulos de alto nivel sean independientes de los
detalles de implementación del módulo de bajo nivel. El
principio establece:
Los módulos de alto nivel no deberían depender de
los módulos de bajo nivel. Ambos deberían depender de
abstracciones (por ejemplo, interfaces).
Las abstracciones no deberían depender de los detalles.
Los detalles (implementaciones concretas) deben depender
de abstracciones.

Dentro del diseño orientado a objetos, las interfaces

juegan un papel importante ya que son la capa de ab-
stracción que facilita la descripción conceptual del código,
ósea describe la funcionalidad del software. Fig. 6. Ejemplo Inversión de Dependencias
 III. Principio del Egoísmo
El principio del egoísmo es un principio básico para la
programación. Es parecido al principio de Responsabilidad
Única en cierto sentido. La clase programada debe cumplir
las funciones para las cuales fue diseñada. No deben quedar
métodos o funciones sin nada que hacer en la clase.
Todas las clases de un programa deben tener algun tipo
de relación entere todas ellas, sea directa o implicita.

Fig. 7. Ejemplo Principio de egoísmo