patrón de diseño de envío?

Question

Supongamos que tengo una jerarquía de clases en Java:

interface Item { ... }; 
class MusicBox implements Item { ... }; 
class TypeWriter implements Item { ... }; 
class SoccerBall implements Item { ... }; 

y tengo otra clase en el mismo paquete:

class SpecialItemProcessor { 
    public void add(Item item) 
    { 
     /* X */ 
    } 
} 

donde quiero hacer algo diferente para cada tipo de elemento, pero Don 't desea definir esa acción en las diferentes clases Item (MusicBox, TypeWriter, SoccerBall).

Una manera de manejar esto es:

class SpecialItemProcessor { 
    public void add(Item item) 
    { 
     if (item instanceof MusicBox) 
     { 
      MusicBox musicbox = (MusicBox)item; 
      ... do something ... 
     } 
     else if (item instanceof MusicBox) 
     { 
      TypeWriter typewriter = (TypeWriter)item; 
      ... do something ... 
     } 
     else if (item instanceof SoccerBall) 
     { 
      SoccerBall soccerball = (SoccerBall)item; 
      ... do something ... 
     } 
     else 
     { 
      ... do something by default ... 
     } 
    } 
} 

Esto funciona, pero parece muy torpe. ¿Hay alguna forma mejor de hacerlo, cuando conozco casos especiales? (obviamente si Item contiene un método doSomethingSpecial entonces puedo simplemente llamar al método de ese artículo sin importar de qué tipo es, pero si no quiero que ocurra esa diferenciación dentro del mismo artículo, ¿cómo lo manejo?)

Answer 1

Creo que voy a utilizar la idea de la inversión de control y el visitor pattern:

interface Item { 
    public void accept(Visitor visitor); 
    ... 

    public interface Visitor { 
     public void visit(Item item); 
    } 
} 


class MusicBox implements Item { 
    public interface Visitor extends Item.Visitor { 
     public void visitMusicBox(MusicBox item); 
    } 
    ... 
    @Override public accept(Item.Visitor visitor) 
    { 
     if (visitor instanceof MusicBox.Visitor) 
     { 
      ((MusicBox.Visitor)visitor).visitMusicBox(this); 
     } 
    } 
} 

class TypeWriter implements Item { 
    public interface Visitor extends Item.Visitor { 
     public void visitTypeWriter(TypeWriter item); 
    } 
    ... 
    @Override public accept(Item.Visitor visitor) 
    { 
     if (visitor instanceof TypeWriter.Visitor) 
     { 
      ((TypeWriter.Visitor)visitor).visitTypeWriter(this); 
     } 
    } 
} 

class SoccerBall implements Item { 
    public interface Visitor extends Item.Visitorr { 
     public void visitSoccerBall(SoccerBall item); 
    } 
    ... 
    @Override public accept(Item.Visitor visitor) 
    { 
     if (visitor instanceof SoccerBall.Visitor) 
     { 
      ((SoccerBall.Visitor)visitor).visitSoccerBall(this); 
     } 
    } 
} 

y luego hacer lo siguiente, que al menos reduce el cheque instanceof a una por add() llamada :

class SpecialItemProcessor 
    implements 
     MusicBox.Visitor, 
     TypeWriter.Visitor, 
     SoccerBall.Visitor, 
     Item.Visitor 
{ 
    public void add(Item item) 
    { 
     item.accept(this); 
    } 
    @Override public void visitMusicBox(MusicBox item) 
    { 
     ... 
    } 
    @Override public void visitTypeWriter(TypeWriter item) 
    { 
     ... 
    } 
    @Override public void visitSoccerBall(SoccerBall item) 
    { 
     ... 
    } 
    @Override public void visit(Item item) 
    { 
     /* not sure what if anything I should do here */ 
    } 
} 

Answer 2

Podría crear un patrón de puente para Artículo, en el que el otro lado eran los procesos asociados a hacer cuando se llama a add(). También podría agregar un método de fábrica a la mezcla.

class SpecialItemProcessor { 
    public void add(Item item) 
    { 
    Process p = Item.createCorrespondingProcessor(p); 
    p.doWhenAddin(); 
    } 
} 

Espero que esto ayude.

Answer 3

En Java puede hacer varias expediciones con un patrón de visitante (-like). Las implementaciones de elementos no necesitan contener la lógica de procesamiento, solo necesitan un tipo de método accept().

public interface Item { 
/** stuff **/ 

void processMe(ItemProcessor processor); 

} 

public interface ItemProcessor { 

void process(MusicBox box); 

void process(SoccerBall ball); 

//etc 

} 

public class MusicBox implements Item { 

    @Override 
    public void processMe(ItemProcessor processor) { 
    processor.process(this); 
    } 

} 

public class ItemAddingProcessor implements ItemProcessor { 

    public void add(Item item) { 
    item.processMe(this); 
    } 

    @Override 
    public void process(MusicBox box) { 
    //code for handling MusicBoxes 
    //what would have been inside if (item instanceof MusicBox) {} 
    } 

//etc 
} 

Answer 4

¿Por qué no definir alguna función de devolución de llamada a la interfaz del artículo?

public Interface Item { 
    void onCallBack(); 
} 

Luego, en cada clase que implementa un elemento, como MusicBox, debe implementar la función de devolución de llamada.

public class MusicBox { 
    @override 
    public void onCallBack() { 
    // business logic 
    ... 
    ... 
    } 
} 

A continuación, puede crear un despachador, cuyo nombre es "SpecialItemProcessor".

public SpecialItemProcessor { 
    private final Item _item; 

    public SpecialItemProcessor(Item item) { 
    _item = item; 
    } 

    public dispatch() { 
    _item.onCallBack() 
    } 
} 

Y luego, en la clase de cliente que contiene el SpecialItemProcessor simplemente podría llamar al método, como:

public void XXXX() { 
    .... 
    SpecialItemProcessor specialItemProcessor = new SpecialItemProcessor(new MusicBox()); 
    specialItemProcessor.dispatch(); 
    .... 
} 

En realidad, en C++, este es el enlace dinámico. Y esta es la razón por la cual existe una clase abstracta pura ...