¿Soy el único que a veces adopta la forma aparentemente fácil pero incorrecta de ciertas situaciones de diseño? Admitiré que hice mi parte de objetos cuestionables de Singleton. Además de eso, he sido conocido por hacer uno o dos objetos de Dios para que las cosas parezcan más fáciles.¿Qué patrones anti usas aunque sepas que no deberías?
¿Alguna vez ha utilizado un antipatrón aunque sabe que no debería?
El anti-patrón God Object es un error fácil de realizar. A veces puede parecer demasiado trabajo para romper clases. Luego, en algún momento más tarde, pagas por ello. He encontrado que este antipatrón va de la mano con un acoplamiento firme.
El patrón de bloqueo de proveedor también puede ser difícil de evitar cuando utiliza idiomas específicos del proveedor.
Es posible que desee editar eso para decir "Dios". – CTT
Me gusta la idea de un objeto gob, todo boca y nada de pantalones, es complicado pero en realidad no hace mucho. – Tom
De hecho, pensé que estabas usando jerga. Una pena que lo hayas cambiado, podrías haber empezado una nueva ola, je. –
Copy and paste contra el patrón
usted puede encontrar más información en la misma:
Se está tratando muy fácil de hacer algo flexibles, y terminando con el Inner Platform Effect . Soy culpable de bases de datos internas, por ejemplo.
Y a veces es demasiado tentador codificar las cosas usted mismo en lugar de usar esa versión pre-enlatada similar - Not Invented Here. Trato de evitarlo, pero ...
Siempre hay esa cosa específica un vendedor que se agrega a una parte específica de la funcionalidad, ya que tiene más sentido que escribir por sí mismo. He pasado mucho tiempo pateándome para tomar esta decisión más adelante.
En los comentarios y creo que es una respuesta, el patrón de Singleton.
Es una forma de lograr variables globales cuando un idioma (como Java) no lo admite. Este es uno de esos patrones en los que nunca debes usar, excepto cuando lo necesites. Lo importante es poder diferenciar entre cuando necesita tener una variable global (hay instancias) y cuando solo quiere una.
Existen problemas con los singleton más allá de los serios problemas de introducción de estado global, en Java, por ejemplo, solo son únicos dentro del cargador de clases con cargadores de múltiples clases, puede terminar con múltiples copias.
Tengo curiosidad sobre el singleton. La salida perezosa es usar simples globos comunes, así que ¿por qué se toma la molestia adicional de usar un antipatrón * más * complejo? Los globales pueden ser malos, pero en general son menos malos que los singletons. Y más fácil de codificar también. – jalf
Mi creencia es que los Singleton son intrínsecamente un mal patrón de diseño; en mi opinión, solo se pueden usar en casos excepcionales de controladores de hardware. En la mayoría de los otros casos, simplemente introducen el estado global en mi entorno OOP que daña los objetivos de calidad del diseño, como la portabilidad. –
Continúa del comentario anterior: Sin embargo, a menudo justifico los singletons con la siguiente lógica: "Solo necesito uno de estos, así que lo convertiré en un singleton", aunque lo que realmente quiero en el fondo es una variable global. –