¿Existe un patrón de diseño concebible para cualquier programa orientado a objetos? Pregunto esto porque recientemente vi una implementación de una Doorclase con un Lock. Formaba parte de una prueba y la respuesta decía que el código sigue el patrón Objeto nulo:
class Lock
{
public:
virtual void close() = 0;
virtual void open() = 0;
virtual bool is_open() const = 0;
virtual ~Lock() { }
};
class DummyLock
: public Lock
{
private:
DummyLock();
DummyLock(const DummyLock&) = delete;
DummyLock& operator=(const DummyLock&) = delete;
private:
void close() { }
void open() { }
bool is_open() const { return true; }
public:
static DummyLock m_instance;
};
class Door
{
public:
Door() : m_lock(DummyLock::m_instance) { }
Door(Lock &lock) : m_lock(lock) { }
public:
Lock& get_lock() const { return m_lock; }
private:
Lock &m_lock;
};
Esto me hizo pensar: este código sigue un buen patrón de diseño a pesar de que la descripción es muy simple (esta clase está diseñando una clase de puerta con cerradura), así que si estoy escribiendo un código más complejo, ¿ siempre debería haber algún patrón de diseño que yo estoy siguiendo?
3
Muy relacionado: Elegir el patrón de diseño correcto
¿Crees que podrías hablar completamente en modismos? ¿No? Entonces no deberías construir tus programas juntando patrones de diseño.
—
Kilian Foth
En su ejemplo, el patrón de objeto Nulo solo se agrega con fines académicos, no introduce "un buen diseño" en este código.
—
Doc Brown
@djechlin: en otras palabras, use el patrón de diseño de "dos palabras" :)
—
Michael Shaw
El problema es que muchas personas creen que los patrones de diseño son un sustituto del pensamiento y un sustituto de la experiencia (lo que implica una cierta cantidad de prueba y error). No puede tomar un libro lleno de patrones de diseño y armarlos como Tinker Toys para producir una aplicación con un tamaño y complejidad no triviales y una calidad decente. Incluso los programadores experimentados a menudo necesitan probar dos o tres diseños antes de encontrar uno que funcione.
—
Daniel R Hicks