PDF de programación - Retomando el Control Principios de Diseño Ágil, Patrones y Antipatrones

Retomando el Control

Principios de Diseño Ágil, Patrones

y Antipatrones

Dr. León Welicki

ONO (Cableuropa S.A.U.)

Universidad Pontificia de Salamanca, campus Madrid

Objetivo

• Reflexionar juntos sobre la disciplina de

construcción de software y algunas de
sus dificultades principales

© León E. Welicki, 2007

Fuera de Control

© León E. Welicki, 2007

La evolución y la informática

© León E. Welicki, 2007

Pregunta inicial

• ¿Orientación a Objetos es fácil o es difícil?

© León E. Welicki, 2007

Muchos conceptos que aprender y entender

 Herencia
 Polimorfismo
 Ocultación de

información
 Sobrecargas
 Métodos virtuales
 Clases abstractas
 Interfaces
 Abstracción
 Agregación
 Especialización

© León E. Welicki, 2007

 Herencia múltiple
 Composición
 Delegación
 Dual dispatch
 Dynamic dispatch
 Responsabilidades
 Elementos estáticos
 Responsabilidades
 Colaboraciones
 Realización
 Etc., etc., etc…

Contamos con herramientas muy potentes

• Facilitan el proceso de construcción

• Soluciones más complejas y funcionales

con menor esfuerzo

• ¿Sabemos cómo utilizarlas?

– Marketing vs Ingeniería
– Adecuación al dominio
– ¡Potencia sin control!

© León E. Welicki, 2007

El mono astronauta

© León E. Welicki, 2007

Las herramientas y su contexto

¡ Tenemos que saber cómo y cuándo
usarlas, porque sino se vuelven en

nuestra contra !

© León E. Welicki, 2007

Queremos construir esto…

© León E. Welicki, 2007

¡Pero muchas veces el resultado es este!

© León E. Welicki, 2007

(anti)Patrón: Big Ball of Muds

• Describe el tipo de arquitectura más desplegado: Big Balls of

Mud

– “the architecture that actually predominates in practice”

– “the de-facto standard sotfware architecture”

– “People build big balls of mud because they work. In many domains,

they are the only things that have been shown to work”

– “Not every backyard storage shack needs marble columns”

– “There are significant forces that can conspire to compel architecture

to take back seat to functionality”

– “Doesn’t require a hyperproductive virtuoso architect at every

keyboard”

• Brian Foote y Joe Yoder (PLoP 98)

© León E. Welicki, 2007

Consecuencia de una combinación de factores

© León E. Welicki, 2007

Algunas Malas Prácticas

• Spaghetti Code
• Throwaway Code
• Sweeping it under the rug
• Reconstruccion

© León E. Welicki, 2007

Algunos “malos olores” en el diseño...

• Rigidez: el sistema es difícil de cambiar porque cada cambio

fuerza muchos otros cambios en otras partes del sistema

• Fragilidad: los cambios producen errores en el sistema en

componentes que no tienen relación conceptual con la parte que
ha sido cambiada

• Inmobilidad: es difícil separar el sistema en componente que

puedan ser reutilizados en otras aplicaciones.

• Viscosidad: hacer las cosas bien es mucho mas difícil que

hacerlas mal

• Complejidad Innecesaria

• Repetición Innecesaria

• Opacidad: difícil de entender

© León E. Welicki, 2007

Ejemplo de mal diseño: Rigidez e Inmobilidad

Copy

enum OutputDevice {printer, disk};

void Copy(OutputDevice dev){

int c;

while((c = ReadKeyboard())!= EOF)

Read

Keyboard

Write
Printer

Write
Disk

}

if(dev == printer)

WritePrinter(c);

else

WriteDisk(c);

void Copy(){

int c;

while ((c = ReadKeyboard()) != EOF)

WritePrinter(c);

}

© León E. Welicki, 2007

Pero este no es el problema de fondo

• Problema: amplio conocimiento de los

productos, pero gran desconocimiento de:

– los conceptos básicos sobre los que se fundan

– las consecuencias de gran parte del código

que escribimos

– la tecnología e ingeniería asociada

– ¡Este problema atañe a la complejidad

accidental de construir software!

© León E. Welicki, 2007

No hay balas de plata

• El software y los hombres-lobo no son tan

distintos…

• No existen las soluciones mágicas ni

estrategias generalizables para el
desarrollo exitoso de software

• Problemas
– Esenciales
– Accidentales

© León E. Welicki, 2007

Complejidad Esencial

• Complejidad

– No hay dos partes iguales
– Escalar una entidad de software no es repetir sus

participantes

• Conformidad

– Falta de principios axiomáticos (como en física o

matemáticas)

• Cambiabilidad

– Sujeto a constantes cambios, incluso luego de ser

entregado al cliente

• Invisibilidad

– El software es “invisible and unvisualizable”

© León E. Welicki, 2007

Un caso típico de gestión de requisitos

Hombre que busca pareja

Agencia Matrimonial “Charly”

Hola, busco una mujer

guapa, compañera,

divertida y con carácter

¡Tengo a la persona

ideal para ti!

© León E. Welicki, 2007

Un caso típico de gestión de requisitos

Hombre que busca pareja

Agencia Matrimonial “Charly”

Esto no es lo que yo tenia

en mente. ¡Exijo que

soluciones esto ya mismo!

De momento, esto es lo que

hay…Podemos hacer un
refactoring o realizar una

nueva búsqueda

© León E. Welicki, 2007

La potencia no es suficiente

Potencia sin Control

Potencia con Control

© León E. Welicki, 2007

Generalmente gana la potencia sin control

© León E. Welicki, 2007

Sad but true..

© León E. Welicki, 2007

El desarrollador y las herramientas

• Las grandes productoras

de software contratan a los
mejores ingenieros

• La falta de conocimiento

de ingeniería deja en
desventaja a los
desarrolladores de
software “empresarial”

– Riesgo: convertirse en un

consumidor de productos
e ideas sin capacidad de
cuestionar

– Las herramientas y los

paradigmas nos dominan
y determinan la forma en
que construimos software

© León E. Welicki, 2007

Retomando el control

• Es importante tomar el control de los desarrollos que

creamos

– entender los conceptos fundamentales de la tecnología que

utilizamos

– debemos controlar las herramientas de desarrollo y no al

revés

• A continuación…

– presentaremos manifiesto ágil

– estudiaremos 5 principios de diseño OO presentes en

muchos frameworks y sistemas

– revisaremos el concepto de patrón y algunos catálogos

– presentaremos a los antipatrones más conocidos

© León E. Welicki, 2007

El Manifiesto Ágil

© León E. Welicki, 2007

http://agilemanifesto.org/

Métodos ágiles

• XP
• Scrum
• Crystal Clear
• Lean Software Development
• Feature Driven Development (FDD)
• Agile modelling
• Etc., etc., etc…

© León E. Welicki, 2007

Diseño ágil

• Utilizar los principios del manifiesto ágil

para establecer un proceso y un conjunto
de prácticas que nos permitan desarrollar
software de calidad entregando valor al
cliente en plazos cortos de tiempo y con
actitud positiva al cambio

© León E. Welicki, 2007

Algunas de nuestras herramientas

• Principios
• Heurísticas
• Patrones
• Frameworks

© León E. Welicki, 2007

Post-Agilismo

• “In an industry that seems to look for

silver-bullet solutions, it’s important for us
to be skeptics. We should be skeptical of
what we’re developing, but also of the
methodologies, processes, and tools on
which we rely. We should continuously
strive for improvement”
http://www.kohl.ca/blog/archives/000166.html

© León E. Welicki, 2007

5 Principios de Diseño

• Single Responsibility Principle
• Open-Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

© León E. Welicki, 2007

Single Responsibility Principle (SRP)

A class should have
one, and only one,
reason to change

© León E. Welicki, 2007

Single Responsibility Principle (SRP)

• Es importante pensar en responsabilidades de

las entidades
– Las responsabilidades pueden verse como “razones de

una clase para cambiar”

• Este principio esta relacionado / derivado del

concepto de cohesión

• Relación con el anti-patrón “God Class”

– En este caso, se viola claramente el SRP

– Otras violaciones más sutiles se encuentran

frecuentemente en la gestión de la persistencia

• Especialmente al usar DDD

© León E. Welicki, 2007

Single Responsibility Principle (SRP)

Todo en una…

Responsabilidades separadas

Un cambio en cualquier
funcionalidad requiere
modificar 4vector

Cambios en “rotations” o “boosts”
no tienen impacto en 4vector

© León E. Welicki, 2007

Single Responsibility Principle (SRP)

Computational

Geometry
Application

Rectangle
+draw():void
+area():integer

Graphical
Application

GUI

La clase Rectangle puede cambiar por dos fuentes no relacionadas

1) Computational Geometry Application (CGA), por ejemplo, añadiendo

una función para calcular el área de tipo “double”

2) Graphical Application (GA), por ejemplo, añadir un metodo draw() para

pintar con el estilo de Windows Vista

Cualquiera de estos cambios impacta en todas las aplicaciones cliente

© León E. Welicki, 2007

Single Responsibility Principle (SRP)

Computational

Geometry
Application

Graphical
Application

Geometric
Rectangle
+area():double

Graphic

Rectangle
+draw():void

GUI

• El paquete CGA ya no es dependiente del lado gráfico de Rectangle y por

lo tanto es ahora independiente del paquete GUI. Los cambios causados
por la aplicacion gráfica ya no requieren recompilar CGA

• De todos modos, los cambios en CGA todavia hacen que sea necesario

recompilar GA

© León E. Welicki, 2007

Single Responsibility Principle (SRP)

Computational

Geometry
Application

Graphical
Application

Geometric
Rectangle
+area():double

Rectangle

-double length
-double width
+getLength():dobule
+getWidth():dobule

Graphic

Rectangle
+draw():void

GUI

•

•

La clase Rectangle contiene los atributos y operaciones primitivas de los
rectángulos.

Las clases GeometricRectangle y GraphicalRectangle son
independientes

• Cambios en CGA o GA no provocan respectivas recompilaciones

© León E. Welicki, 2007

Open Closed Principle (OCP)

Software entities
(classes, modules,
functions, etc.) should be
open for extension but
closed for modification

© León E. Welicki, 2007

Open Closed Principle (OCP)

• Abierto para extensión…

– El comportamiento del módulo puede ser extendido

• Cerrado p