2008-09-24 10 views
11

¿Existe un specfic Gang Of Four Design Pattern que utiliza con frecuencia, pero que apenas se ve utilizado en los diseños de otras personas? Si es posible, describa un ejemplo simple donde este patrón puede ser útil. No tiene que ser necesariamente un patrón de Gang Of Four, pero incluya un hipervínculo a la descripción del patrón si elige un patrón que no sea GoF.¿Qué patrones de diseño están subutilizados?

Dicho de otra manera:
¿Cuáles son algunos buenos patrones de diseño/útiles que yo, o alguna otra persona que tiene un conocimiento superficial de los patrones principales, no puede ya saben?

Respuesta

5

¿Patrón de estrategia tal vez? No veo mucha gente usándolo y es bastante útil cuando los cálculos cambian o se pueden acumular juntos. Lo uso cuando una parte del cálculo puede ser reemplazada por otro cálculo. A menudo en el programa que se utiliza para la tasa de empresa para el producto.

Aquí es un poco de documentación:

4

El patrón del visitante parece ser difícil de entender para muchos nuevos desarrolladores. Lo estaba usando para el cálculo cuando tuve la posibilidad de obtener valor para Country> State> City> House. De esta forma, no he tenido que cambiar la cantidad de datos que tenía en cada subcolección. Escogí el visitante correcto y la respuesta final fue obtener el número de países, estados o ciudades.

8

Steve Yegge escribió un (típicamente) de largo blog entry about the Interpreter Pattern, por lo que la afirmación de que este patrón es el único patrón GoF que puede hacer que el código "más pequeño", y es penalmente subutilizado por programadores que de otra manera están bastante cómodos con los otros patrones de GoF. Soy uno de esos programadores. Nunca he usado el patrón de Interpreter, aunque reconozco que es importante para cosas como DSL. De todos modos, es un ensayo muy estimulante si tienes la fortaleza intestinal para leer una publicación completa de Yegge.

5

visitante tiene una mala reputación, en parte debido a algunos problemas reales

  • dependencia cíclica entre Vistor y jerarquías Visitado
  • que se supone que arruinar la encapsulación mediante la exposición de las clases Visitado el funcionamiento interno

y en parte debido a la exposición en el libro de GOF, que enfatiza el recorrido de una estructura en lugar de agregar funciones virtuales a una jerarquía cerrada.

Esto significa que no se considera apropiado, por ejemplo, para resolver el problema del doble envío en lenguajes tipados estáticamente. Ejemplo: un mensaje o un sistema de paso de eventos en C++, donde los tipos de mensajes son fijos, pero queremos extenderlos agregando nuevos destinatarios. Aquí, los mensajes son solo estructuras, por lo que no nos importa encapsularlos. SendTo() no sabe qué tipo de Message o MessageRecipient tiene.

#include <iostream> 
#include <ostream> 
using namespace std; 

// Downside: note the cyclic dependencies, typically expressed in 
// real life as include file dependency. 
struct StartMessage; 
struct StopMessage; 

class MessageRecipient 
{ 
public: 
    // Downside: hard to add new messages 
    virtual void handleMessage(const StartMessage& start) = 0; 
    virtual void handleMessage(const StopMessage& stop) = 0; 
}; 

struct Message 
{ 
    virtual void dispatchTo(MessageRecipient& r) const = 0; 
}; 

struct StartMessage : public Message 
{ 
    void dispatchTo(MessageRecipient& r) const 
    { 
     r.handleMessage(*this); 
    } 
    // public member data ... 
}; 

struct StopMessage : public Message 
{ 
    StopMessage() {} 

    void dispatchTo(MessageRecipient& r) const 
    { 
     r.handleMessage(*this); 
    } 
    // public member data ... 
}; 

// Upside: easy to add new recipient 
class RobotArm : public MessageRecipient 
{ 
public: 
    void handleMessage(const StopMessage& stop) 
    { 
     cout << "Robot arm stopped" << endl; 
    } 

    void handleMessage(const StartMessage& start) 
    { 
     cout << "Robot arm started" << endl; 
    } 
}; 

class Conveyor : public MessageRecipient 
{ 
public: 
    void handleMessage(const StopMessage& stop) 
    { 
     cout << "Conveyor stopped" << endl; 
    } 

    void handleMessage(const StartMessage& start) 
    { 
     cout << "Conveyor started" << endl; 
    } 
}; 

void SendTo(const Message& m, MessageRecipient& r) 
{ 
    // magic double dispatch 
    m.dispatchTo(r); 
} 

int main() 
{ 
    Conveyor c; 
    RobotArm r; 

    SendTo(StartMessage(), c); 
    SendTo(StartMessage(), r); 
    SendTo(StopMessage(), r); 
} 
2

Si estamos hablando de patrones no GOF continuación Monitor Object es el 'Hello World' de la programación OO concurrente. Me sorprende cuántos programadores logran no haber oído hablar de él, o prefieren diseñar sus propios esquemas de sincronización ad hoc.