diseño de patrones, Visitor.

En wikipedia:
http://en.wikipedia.org/wiki/Visitor_pattern

El mismo ejemplo que alli viene...modelemoslo:

 y se usaria :

public class VisitorDemo {
     public static void main(String[] args) {
         CarElement car = new Car();
         car.accept(new CarElementPrintVisitor());
         car.accept(new CarElementDoVisitor());
     }
 }

Veamos más ejemplos:

en http://www.javaworld.com/javatips/jw-javatip98.html aparece la pregunta clave. 

¿Como se gestionan operaciones sobre colecciones de objectos diferentes?. 

Esta es la pregunta cuya respuesta es el patron visitor. El ejemplo que aquí te ponen es que si al iterar sobre la collección tengo que poner un if por cada tipo de objeto que pueda encontrarme, el codigo alcanza pronto una cantidad inaceptable de ifs. 

En este caso teniendo una colección de String, Long..y objectos diferentes se puede crear el siguiente diagrama de clases.

Legenda:

Diseño de patrones, Strategy

De la wikipedia:

http://en.wikipedia.org/wiki/Strategy_pattern

Busquemos algún ejemplo...
En http://java.dzone.com/articles/design-patterns-strategy

La verdad es que no hay mucho que comentar. Se desacopla la conversión concreta de su uso. Se accede a esta funcionalidad de manera indirecta, doblemente indirecta. Una por que se comprime desde el contexto pero no se accede al compresor directamente sino que se encapsula en el método compressArchive(). Y otra por que el compressor al que este método accede es generico y por tanto solo se hace directa en la ejecución, no en la compilación.

Diseño de patrones, Observer

de la maravillosa página :
http://sourcemaking.com/design_patterns/observer/java/1

que se utilizaría...

public static void main( String[] args ) {
    Subject sub = new Subject();
    // Client configures the number and type of Observers
    new HexObserver( sub );
    new OctObserver( sub );
    new BinObserver( sub );
    Scanner scan = new Scanner();
    while (true) {
      System.out.print( "\nEnter a number: " );
      sub.setState( scan.nextInt() );
    }
  }

 Asi que por cada número este cambiara el estado de el sujeto observado (subject) y esto accionará la notificación de sus observers y el update de cada  uno cuyo metodo depende directamente del estado del subject.

Diseño de patrones, Mediator

http://sourcemaking.com/design_patterns/mediator

Util para desacoplar comunicaciones....

 de modo que queden

veamos en http://www.dofactory.com/Patterns/PatternMediator.aspx#_self1

y como usarlo...

  class MainApp

  {

    /// <summary>

    /// Entry point into console application.

    /// </summary>

    static void Main()

    {

      ConcreteMediator m = new ConcreteMediator();

      ConcreteColleague1 c1 = new ConcreteColleague1(m);

      ConcreteColleague2 c2 = new ConcreteColleague2(m);

      m.Colleague1 = c1;

      m.Colleague2 = c2;

      c1.Send("How are you?");

      c2.Send("Fine, thanks");

      // Wait for user

      Console.ReadKey();

    }

  }

Patrones de diseño, Chain of responsibility

 Esta imagen de http://sourcemaking.com/design_patterns/chain_of_responsibility es muy ilustrativa:

de la misma página el UML :

Es muy revelador la afirmación que allí nos hacen. Chain of Responsibility, Command, Mediator y Observer son diferentes maneras de desacoplar el origen y destino en una comunicación.

y el ejemplo que allí ponen en java solo tiene una clase.Un Handler que bien podría ser "Handler One" sino fuera por que no hereda de nadie. A parte se genera un cliente que con una Array de Handlers sobre los que se executa handle. Este método devuelve boolean que mientras es falso sigue iterando sobre la cadena de Handlers.

sourcemaking.com/design_patterns/chain_of_responsibility/java/1

class Handler
{
    private static java.util.Random s_rn = new java.util.Random();
    private static int s_next = 1;
    private int m_id = s_next++;

    public boolean handle(int num)
    {
        if (s_rn.nextInt(4) != 0)
        {
            System.out.print(m_id + "-busy  ");
            return false;
        }
        System.out.println(m_id + "-handled-" + num);
        return true;
    }
}

public class ChainDemo
{
    public static void main(String[] args)
    {
        Handler[] nodes = 
        {
            new Handler(), new Handler(), new Handler(), new Handler()
        };
        for (int i = 1, j; i < 10; i++)
        {
            j = 0;
            while (!nodes[j].handle(i))
              j = (j + 1) % nodes.length;
        }
    }
}

Sospechoso que no se haya respetado el esquema. Queda así desacoplado quien 

envia el mensaje de quien lo recibe?

Vamos con otro. 

http://java.dzone.com/articles/design-patterns-uncovered-chain-of-responsibility

En este caso en vez de hacerse un triste Array se genera una cadena a través de los propios Handlers.

http://howtodoinjava.com/2013/04/22/chain-of-responsibility-design-pattern/

Diseño de patrones, Abstract Factory

Yo recomendaría que se mirara primero Factory Method.
Abstract Factory Method parece lo que dice, una abstracción del Factory Method donde se nos permite crear objetos de manera indirecta  Este patron parece subir un nivel más para crear de forma indirecta  factorias creadoras de objectos. Bien podría llamarse Meta Factory Method.

En http://en.wikipedia.org/wiki/Abstract_factory_pattern

hacer de la factoria un producto abstracto que pueda cambiarse y con el todos sus creaciones.

Aqui lo mismo. Se genera en función de la factoría creada se generarán una familia u otra de productos.

http://javapapers.com/design-patterns/creational-design-pattern/abstract-factory-pattern/
De aquel codigo se extrae el siguiente modelo.

Hecho de menos una variable que me haga accesible lo que produce Wonderland. Esta fabrica crea animales que ejecutan acciones....breath, pero no me da acceso a ellos. No puedo así utilizarlos en el resto de un cliente. Creo que la finalidad de la abstract factory, que es crear familias de productos, no se ve así cumplida. Yo imagino un código en el que hay una animal factory desperdigada que instancia diferentes factorias en funcion de alguna lógica. Vease el mismo código de uso de la página referida:

public class SampleAbstractFactory {

  public static void main(String args[]){

    new Wonderland(createAnimalFactory("water"));

  }

  public static AnimalFactory createAnimalFactory(String type){

    if("water".equals(type))

      return new SeaFactory();

    else

      return new LandFactory();

  }

}

la intención aquí es crear un wonderland. Yo me quedaría con el método createAnimalFactory(String type) que según reciba "water" o no creara Sharks o elefantes. Insisto Meta Factory Method.

http://howtodoinjava.com/2012/10/29/abstract-factory-pattern-in-java/

http://www.javapractices.com/topic/TopicAction.do?Id=128
http://www.allapplabs.com/java_design_patterns/abstract_factory_pattern.htm

Patrones de diseño, Factory Method

Factory methods soluciona dos problemas:
- acoplamiento en la creación: el comando new acopla la clase donde se escribe con la que se llama. Si mañana la creación del objeto instanciado cambia de parametros todos sus instanciaciones se verán afectadas.
-

En http://java.dzone.com/articles/design-patterns-factory

Parece que es un clasico.
http://www.javaworld.com/javaqa/2001-05/02-qa-0511-factory.html

En este caso vemos que la factoria tiene cierta lógica que es la que decide que tipo de objecto va a devolvernos. Ademas no trabajamos con una fabrica abstracta. No parece acoplarse mucho al paradigma.


Veamos otro:

 Pasa un poco lo mismo que la anterior. Yo diría que es peor. No hay Factoria Abstracta y ademas el método con el que obtenemos el producto necesita parametros. Parece que la solución genera los mismos problemos que pretende solucionar. Provee una solución a el problema concreto de que crear pero sigue acoplando la creación allí donde se instancie. Si mañana la factoria cambia sus parametros de entrada tendrá que modificarse allí donde se haya utilizado.

Patrones de disenyo, Builder

De stackoverflow:

http://stackoverflow.com/questions/328496/when-would-you-use-the-builder-pattern

vamos a hacer pizzas....

... no hay manera de encajar lo que pone en ese util ejemplo con el patron Builder...

o otro del mismo tipo

http://www.javacodegeeks.com/2012/07/builder-design-pattern-in-java.html

y otro:

http://kodelog.wordpress.com/tag/telescopic-constructor-pattern/

Veamos otro:
http://sourcemaking.com/design_patterns/builder/java/2

Otra posible implementacion seria hacer un Builder con un interfaz.

http://javapapers.com/design-patterns/creational-design-pattern/builder-pattern/

Un clasico como el de GoF:

http://www.oodesign.com/builder-pattern.html

About Agile From Alistair Cockburn

• ·         Convection Currents of Information
• ·         Erg-seconds

Work and time
With every speech act, X radiates both information
and energy into the environment around

• ·         Osmotic Communication

We have seen three separate effects that office layout has on communication costs within a project
- The reduction in cost when people discover information in background sounds (osmotic communication)
- The overall cost of detecting and transfering information (erg-seconds)
- The lost opportunity cost of not asking
So if we put them into one room not always will work that will depend on:
Three more issues affect the answer in any one particular setting:

- The sort of information being shared - mixing programmers with bussines experts
- People's personal preferences - Some people really value their quiet, private offices
- Drafts  - Drafts are unwanted information, in our newly extended metaphor. Too thin walls let drafts pass.

Osmosis across Distances - voice over-ip services

• ·         Drafts...explained before
• ·         Information Radiators

Two characteristics are key to a good information radiator. The first is that the information changes over time. This makes it worth a person's while to look at the display. 

With information
radiators, the passers by need not ask any question; the
information simply hits them as they pass. The other characteristic is that it takes very little energy to view the display. Size matters when it comes to information radiators - the bigger the better, as many people remind me. 

A second use of information radiators, suited for any project using increments of a month or less, is to show the work breakdown and assignments for the next increment

A third use of flipchats as information radiators is to show the results of the project's periodic reflection workshop.

A fourth use of information radiators is to show everyone the user stories delivered, in progress, the number of acceptance tests written and met, and so on.

• ·         Applying the Theory of Hot Air

take advantage of convection currents of information and osmotic communications

Caves and Common: provision for both private and project space. 

Skunkworks: "...the aerodynamics group in my office began talking through the open door to the structures bunch about calculations on the center of pressures on the fuselage, when suddenly I got the idea of unhinging the door between us..."

• ·         Jumping Communications Gaps
• ·          Modalities in Communcaiton

Peoble at whiteboard have Physical Proximity, Three dimensionality, Smell, Kinasthetics, Touch,Sounds,Visuals(Gestures),Cross-modality timing(combination of all above),Low latency,Real time question and answers, all this bring trust and learning.

•          The Impact of Removing Modalities

Physical Proximity (example...weak one)

Visuals, by phone you have not facial expresion, gestures...

Voice, by email we loose vocal inflexions and  more important Real time question and answers

• ·         Making Use of Modalities

 Will increment comunications channel's temperature

• ·         Stickiness and Jumpting Gaps across Space

So why did they need to write use cases at all? The answer is: To give the information some stickiness.

whiteboards (static information radiators) and people (dynamic information radiators).

So a reunion on a white boards or sharing papers will got convection currents of information, osmotic Agile Software Development communication, face-to-face communication, realtime question and answer.

A colleague, Mohammad Salim, responded to this situation by covering all the walls and hallways with rolls of butcher paper,

• Jumping Gaps across Time

However, on long-running projects, it turns out to be critically important that the chief architect stays around! This person's contribution is to keep memories of key ideas alive across changing development teams. Once again, people are used as the archival medium!

• ·         Teams as Communities

People should pull to aprox same direction.

• .     The Project Priority Chart

aligning efforts

• ·         Amicability and Conflict

amicability is 

• ·         Building "Team" by Winning
• ·         Team Cultures and Subcultures
• ·         Teams as Ecosystems
• ·         Mapping Methodology to Ecosystem

So if we put them into one room not always will work that will depend on:

• Three more issues affect the answer in any one
  particular setting:
  · The sort of information being shared - mixing programmers with bussines experts
  · People's personal preferences - Some people really value their quiet, private
  offices
  · Drafts  - Drafts are unwanted information, in our newly
  extended metaphor. Too thin walls let drafts pass.

• Osmosis across Distances - voice over-ip services

Information Radiators

Patrones de Diseño, Bridge.

Buscando en la red algún ejemplo claro del patrón de diseño Bridge no tenía la seguridad de haberlo entendido por lo que busque varios ejemplos que me permitieran entender la esencia del mismo. Supuse que lo que tuvieran en común sería la mismisima definición del concepto. El resto las diferentes especies.

Lo primero será como muestran las buenas prácticas el gráfico UML.











Del cual hemos de memorizar los nombres para poder señalar con mayor facilidad cada uno de los elementos de cada implementación concreta. Implementor, ConcreteImplementor, Abstraction y RefinedAbstraction.


Buscando implementaciones del patrón me encuentro esta:

http://javapapers.com/design-patterns/bridge-design-pattern/

que pasado a UML a través de https://app.genmymodel.com/genmymodel queda en :

todo esto se ha hecho para evitar la siguiente composición.


Que tiene dos defectos que soluciona el patron Bridge. El primero es que cada subclase depende directamente, hereda, de un padre de modo que cada vez que quiera cambiar algo de este sus hijos se veran afectados. Llámesele acoplamiento. A la izquierda si cambio algo de Bike o de Car, sus respectivos produceX y assembleX se verán afectados. Véase, sin embargo, como con el diseño de la parte superior la vinculación del produce o assemble solo es efectiva en tanto que:
manufacture(){
  manufacture1.work();
  manufacture2.work();
}.
Y por tanto un cambio en Bike o en Car no tendrá ninguna consecuencia en produce o assemble.

Sigamos con otro ejemplo. Este de http://www.oodesign.com/bridge-pattern.html

Este grafico yo lo pintaria así:

Y vemos ciertas diferencias. La más evidente es que  CustomerOps o GlobalMarketOps realizan, implementan un interfaz y de este modo no se obliga en tiempo de compilación a escribir un constructor con un argumento del tipo IPersistenceData. Ya eque el interfaz no puede tener nunca un constructor. Y el otro lado de lo mismo es que el interfaz no puede tener ninguna variable instanciable. Asi lo que se pasaba por el constructor de la clase abstracta Vehicle para asignarlo a las instancias de workshop no tiene cabida en este segundo ejemplo. Esto obliga al cliente a gestionar tanto el constructor como sus asignaciones y por tanto es trabajo repetido y que da lugar a errores.
Lo mismo pasa con los

Otra diferencia es que los distintos XData no se acumulan es sus clientes RefinedAbstraction , es decir, se usa uno u otro. No así en el primer ejemplo en el que los diferentes ConcreteImplementor se usaban ambos en el manufacture de sus RefinedAbstraction. No se hace uso en el caso de la persistencia del trabajo acumulativo de cada uno de los.

Por ahora está mucho más exprimido el patrón en el primer ejemplo que en el segundo. También mejor implementado. El abstraction en la persistencia es un interfaz y no debería.

Vayamos a por otro:

Este en http://www.programcreek.com/2011/10/java-design-pattern-bridge/















Este ejemplo me aclara algo. Y es que pone de manifiesto que es la instanciación de RedefinedAbstraction donde se elige el tipo ConcreteImplementor

public class Main {
 public static void main(String[] args){
  ITV tv = new SonyTV();
  LogitechRemoteControl lrc = new LogitechRemoteControl(tv);
  lrc.setChannelKeyboard(100); 
 }
}

el diagrama estaria mejor asi: