design-patterns - pattern - patrones de diseño pdf
¿Qué patrones de diseño están subutilizados? (5)
El patrón Visitor parece ser difícil de entender para muchos desarrolladores nuevos. 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.
¿Hay un patrón de diseño de Gang Of Four que uses con frecuencia, pero que apenas se vea 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.
Dicho de otra manera:
¿Cuáles son algunos patrones de diseño buenos / útiles que yo, u otra persona que tenga un conocimiento pasajero de los patrones principales, puede que no sepan ya?
El visitante tiene una mala reputación, en parte debido a algunos problemas reales
- dependencia cíclica entre Vistor y las jerarquías visitadas
- se supone que arruina la encapsulación al exponer las clases internas visitadas
y en parte debido a la exposición en el libro 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 cuando corresponde, por ejemplo, para resolver el problema del doble despacho 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 tiene MessageRecipient .
#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);
}
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í hay algo de documentación:
Si estamos hablando de patrones que no son de GOF, entonces el Objeto de Monitor es el ''Hola Mundo'' 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.
Steve Yegge escribió una entrada de blog (típicamente) larga sobre el patrón de intérprete , afirmando que este patrón es el único patrón GoF que puede hacer que el código sea "más pequeño", y es criminalmente subutilizado por los programadores que de otro modo 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.