Bajo Acoplamiento

Para determinar el nivel de acoplamiento de clases, son muy buenos
los diagramas de colaboración de UML.

————–

Uno de los principales síntomas de
un mal diseño y alto acoplamiento es una herencia muy profunda.
Siempre hay que considerar las ventajas de la delegación respecto de
la herencia.

Como ejemplo (de mal diseño), en muchos diseños Web se
puede ver como se crea un servlet base con capacidades de paginación y
se hereda de él para construir los demás. La paginación es un servicio
que se podría usar en aplicaciones no Web, por lo que es más adecuado
mantener estas capacidades en clases externas.

Otro ejemplo clásico
se produce cuando se pasan los objetos relacionados con la capa de
presentación a la capa de negocio (HttpRequest, HttpResponse).

Alta Cohesión

—————

Ejemplos de una baja cohesión son clases que hacen demasiadas
cosas.

En todas las metodologías se considera la refactorización. Uno de
los elemento a refactorizar son las clases saturadas de métodos.

Ejemplos de buen diseño se producen cuando se crean los denominados
«paquetes de servicio» o clases agrupadas por funcionalidades que son
fácilmente reutilizables (bién por uso directo o por herencia).

—————-

En java, pensar en interfaces nos fuerza a que nuestros sistemas
sigan los principios de alta cohesión. En algún sitio leí que
una aplicación con menos de 8 interfaces no utiliza correctamente los
conceptos de orientación a objeto … y estoy de acuerdo ….

Experto

La responsabilidad de realizar una labor es de la clase que tiene
o puede tener los datos involucrados (atributos) . Una clase, contiene toda la información necesaria
para realizar la labor que tiene encomendada.

————

Hay que tener en cuenta que esto es aplicable mientras
estemos considerando los mismos aspectos del sistema:

• Lógica de negocio
• Persistencia a la base de datos
• Interfaz de usuario

No tiene sentido considerar que una clase se debe escribir a si
misma en base de datos o formatearse para presentarse en una página
HTML por el hecho de poseer los datos. Estos son elementos
estructuralmente distintos y deben considerarse desde una perspectiva
distinta.

Creador

Se asigna la responsabilidad de que una clase B
cree un Objeto de la clase A solamente cuando

1. B contiene a A
2. B es una agregación (o composición) de  A
3. B almacena a A
4. B tiene los datos de inicialización de A (datos que requiere su
   constructor)
5. B usa a A.

————–

El hecho de crear objetos tiene casuísticas particulares:

• Pool de Objetos
• Caches
• Instancias únicas

Estos casos son candidatos para la utilización de otros patrones
más concretos (de diseño).

————

A la hora de crear objetos en distintos lenguajes hay
que tener en cuenta sus peculiaridades. En Java por ejemplo:

• No confundir referencias y el valor referenciado a
  la hora de retornar objetos desde métodos.

• Conocer la peculiaridad de las String (cadenas
  constantes)

• Identificar problemáticas del recolector de basura y
  el uso de recursos del sistema

• Conocer el ámbito y naturaleza de distintos tipos de componentes

  • En servlets y JSPs pueden descargarse y estar
    activos en más de una máquina virtual.

  • Los servlets y JSPs son multi-thread a priory.

  • Los tags son reciclados en JSP (ojo con valores
    anteriores de atributos de clase).

  • Los EJB se desactivan.

  • etc..

• Y muchas cosas más… que la experiencia nos enseña
  ….

Controlador

Un error muy común es
asignarle demasiada responsabilidad y alto nivel de acoplamiento con el
resto de los componentes del sistema.

———————

En UP (proceso unificado), al construir el modelo de
análisis, existen estereotipos predefinidos que favorecen la separación
de entidades, mecanismos de interfaz y mecanismos de control.

———————

En aplicaciones Web, se tiende a separación de la lógica de presentación
y de la lógica de negocio. Patrones bién conocidos como MVC o Fachada,
son de amplia utilización..

Hay otros muchos patrones relacionados sobre todo en entornos multi-capa
(Core J2EE patterns).

——————–

En el diseño de clases de negocio, cuando no tenemos claro a qué clase pertenece la responsabilidad de
realizar una determinada tarea, crear una clase controlador que se llame igual a
la tarea a desempeñar.

Polimorfismo

——————–

El implementar comportamiento alternativos con sentencias IF-ELSE,
no hace más que limitar la reutilización y crecimiento de la
aplicación. Imagine que una aplicación muestra mensajes distintos en
distintos idiomas…. con IF, al aumentar en uno el número de idiomas,
nos obligaría a añadir un nuevo IF. Con polimorfismo nos limitaríamos
a crear un objeto de una clase polimórfica nueva (bajo acoplamiento,
alta cohesión y potencial reutilización). 

Fabricación Pura

—————

Todo proyecto tiene numerosa factorías potenciales, para
intercambiar fácilmente comportamientos:

• Look&Feel (decoradores y familias de componentes gráficos)
• Sistemas de log
• Clases de acceso a gestor a bases de datos
• Sistemas multi-lenguaje
• Privilegios en base al rol de usuario
• Muchas más capacidades comunes

Indirección

—————–

 Pensar en sistemas middleware y se verá la utilidad de un
modo inmediato.

No hables con extraños

Un método, solamente invocará a métodos de:

• De si mismo (this)
• De su área de parámetros
• Un objeto creado en su propio ámbito
• (los demás los doy por incluidos)

——————–

Un fallo común en la construcción de sistemas Web en la utilización
de variables globales (estáticas) o el acceso desde muchos puntos
desordenadamente a variables de sesión o aplicación (contexto).