Presentación de Arquitectura de Software presentando el diseño arquitectonico abierto- cerrado Open/Close

1. Principio de Diseño Abierto-
Cerrado
Open/Close
Arquitectura de Software
Ernesto Maya.
Erick Voltres.
Hugo Hernández.

2. Historia
● Open/Closed Principle, fue planteado por el Dr. Bertrand Meyer en el libro
"Object Oriented Software Construction“ en 1988.
● Se popularizó junto con el resto de principios S.O.L.I.D. en el libro
“Refactoring: Improving the Design of Existing Code” en 1999 por Martin
Fowler.

3. Definición
Las entidades de software (clases, módulos, funciones…etc), deberían ser
abiertas para la extensión pero cerradas para la modificación.
Robert C. Martin Software Agile Development

4. Características del principio Abierto-Cerrado OCP
● Se refiere a un “buen” diseño Orientado a Objetos
● “Es abierto para la extensión”, se refiere a que si en algún momento los
requisitos van necesitando adaptarse es importante tener un módulo abierto
para tal motivo (según el modelo de negocio, el módulo es extendido)
● “Es cerrado para la modificación”, en caso de ser una aplicación bien
definida, si es abierto sólo se debe entender que se extiende por lo cual el
código original seguirá intacto (cerrado)
● Se resuelve en algunos casos con polimorfismo

5. Principio Abierto / Cerrado OCP
● Las clases que cumplen con OCP tienen dos características:
○ Son abiertas para la extensión.
○ Son cerradas para la modificación.
● El término “extender” no se limita solo a la herencia (extends) en Java,
tambien de puede utilizar polimorfismo para invocar un comportamiento (en
tiempo de ejecución.

6. Principio Abierto / Cerrado OCP
● Finalidad:
○ Conseguir cambios añadiendo nuevo código sin afectar al resto de elementos del diseño.
● Ambigüedad:
○ La dependencia “uno a uno” se transforma en una dependencia de “uno a muchos”.
● Ventajas:
○ Evita que cambios en un módulo afecten a otros módulos.
○ Ayuda a eliminar el riesgo y contener costos.

7. Principio Abierto / Cerrado OCP
● Están abiertos para su extensión.
○ Eso implica que el comportamiento de los módulos puede ser extendido.
● Están cerrados para su modificación.
○ El código fuente del módulo es inalterable.

8. Principio Abierto / Cerrado OCP

9. Principio Abierto / Cerrado OCP

10. Principio Abierto / Cerrado OCP

11. Principio Abierto / Cerrado OCP
Toriyama nos pide un programa para
dibujar a goku
public class DragonBallDrawer {
public void draw (Goku goku){
print("Goku draw");
}
}
public class Goku {
int amigos;
int aventuras;
...
}

12. Principio Abierto / Cerrado OCP
Toriyama le gusta y pide más diseños con forme pasa el anime
Class
Gokuniño
Class
Gokuadolecente
Class
Gokuadulto
Class
Gokumaestro

13. Principio Abierto / Cerrado OCP
Para estas modificaciones algo lógico sería pensar en modificar la clase principal y dibujar los diferentes
tipos de personajes con sus características
public class DragonBallDrawer{
public void draw(Object[] dragonball) {
foreach (Object dragonball : dragonball) {
if(dragonball instanceof Gokuniño){
System.out.println("Goku niño ");
}else if(dragonball instanceof Gokuadolecente){
System.out.println("Goku adolecente ");
}else if(dragonball instanceof Gokuadulto){
System.out.println("Goku adulto ");
}else if(dragonball instanceof Gokuamaestro){
System.out.println("Goku maestro ");
}
}
}
}

14. Principio Abierto / Cerrado OCP
Entonces se debe seguir con la solución de un código cerrado pero abierto a
modificaciones
abstract
class anime
public abstract class Anime {
public abstract void draw();
}
Class
Gokuniño
Class
Gokuadolecente
Class
Gokuadulto
Class
Gokumaestro

15. Principio Abierto / Cerrado OCP
La solución es más simple y se presta a que este código sea cerrado y que las
futuras modificaciones no afecten, además de estar abierto a modificaciones.
public class DragonBallDrawer{
public void draw(Anime[] dragonball){
foreach(Anime anime : dragonball){
anime.draw();
}
}
}

16. Gracias