design patterns - patterns - Patrones de diseño de fuentes de crítica.
factory pattern (6)
El mismo Alan Kay es muy crítico con los patrones porque no cree que el software deba ser tan cacareado. Aquí hay una entrevista del Dr. Dobbs con Kay en 2012 .
"La cosa más desastrosa de la programación, para elegir una de las 10 cosas más desastrosas de la programación, es un movimiento muy popular basado en lenguajes de patrones. Cuando Christopher Alexander hizo eso por primera vez en arquitectura, buscó 2.000 años de formas en que los humanos se pusieron cómodos. Así que en realidad había algo en eso, porque estaba lidiando con un genoma que no había cambiado tanto. Creo que obtuvo unos cuantos cientos de patrones valiosos, pero el error al tratar de hacer eso en computación es la suposición de que sabemos algo acerca de la programación. Por lo tanto, extraer patrones de las prácticas de programación actuales los ennoblece de una manera que no merecen. En realidad, les da más prestigio ".
Estaba leyendo la página de patrones de diseño en Wikipedia, particularmente la sección "Crítica".
¿Podría señalarme algunos artículos o libros sobre las deficiencias de los patrones de diseño?
Estoy seguro de que los patrones de diseño ayudan a estructurar los cursos educativos sobre técnicas de programación, pero no creo que sea útil que se conviertan en una lengua franca en la industria del software. Pueden ser contraproducentes como forma de comunicar el diseño porque obligan al diseño a ajustarse a los patrones establecidos, permiten que el diseño se describa de manera demasiado casual y obligan a cualquiera que intente entender el diseño a leer un libro sobre patrones de diseño.
La mayoría de las críticas a los patrones de diseño que he encontrado se relacionan con un disgusto por la estructuración y el etiquetado de lo que consideran simplemente buenas prácticas orientadas a objetos. La mayoría de los patrones se reducen a la programación para interfaces y otros principios SÓLIDOS . La sensación es que cuando enseñamos patrones, hacemos que los desarrolladores, especialmente los desarrolladores junior, intenten meter todos los problemas en el conjunto de patrones que han aprendido, lo que puede crear problemas más obtusos y engorrosos que si hubieran adoptado un enfoque más "directo". .
Tiendo a estar de acuerdo con el sentimiento de que una vez que comienzas a aprender patrones, tiendes a usarlos en exceso, sin embargo, por lo general, te mueves rápidamente de esa etapa y luego ingresas en una carrera de software mucho más productiva y profesional.
Como beneficio adicional, aquí hay algunas críticas leves de Jeff Atwood y algunos puntos de vista críticos de Mark Dominus.
Los patrones de diseño generalmente se presentan como un conjunto de trucos en un lenguaje de programación específico, generalmente Java o C ++. Por lo general, no se explica cuándo y por qué se debe usar un patrón y cuándo es mejor no usarlo. Generalmente no se explica lo que sucedería en un lenguaje de programación totalmente diferente.
Entonces, uno tiene la impresión de que 1) los patrones de diseño provienen del cielo, inventados por genios, 2) el libro de GoF debe ser memorizado, 3) los patrones deben aplicarse siempre y más en cada situación.
Desde mi punto de vista, los patrones de diseño son muy específicos del idioma (LISP tiene un conjunto de "patrones de diseño" totalmente diferente al de Java) y específico del problema (dependiendo del proyecto, se usa o no se usa un patrón aunque sea "teóricamente" aplicable a este lugar en su código). El libro GoF es un complemento útil de un manual en lenguaje Java, pero no es un conjunto de principios eternos sobre la "programación en general".
Los patrones de diseño se promocionaron mucho hace unos diez años; Me parece que la mayoría de las críticas tienen que ver con la arquitectura general de las aplicaciones y la aplicación de todos los patrones que se puedan imaginar donde sea posible. Este acalorado debate es bastante aburrido cuando elimina el factor de perorata: sí, demasiado de nada no es bueno y para el programador inexperto con un martillo todo parece un clavo.
De vez en cuando, alguien descubrirá que algo que él ha estado haciendo todo el tiempo tiene un nombre y comenta que no merece tener un nombre (sin ver el punto de que los patrones de diseño se refieren a nombrar cosas a veces obvias para que pueda hablar). a cerca de ellos).
Aparte de eso, básicamente te queda el hecho de que algunos lenguajes tienen algunos patrones incorporados y otros no, y el debate académico sobre cómo con el tiempo algunos patrones se convierten en características del lenguaje de programación.
No he visto muchas críticas válidas relacionadas con los patrones de diseño además de eso. Definitivamente existen, a veces son útiles, no tienes que conocerlas todas cuando alguien te despierta a las 3 AM, y eso es todo. :)
Una gran crítica contra los patrones de diseño es acerca de cuán "genéricos" son realmente algunos patrones de diseño. Por ejemplo, la implementación del Patrón de Estrategia parece ser más relevante (y compleja) en lenguajes que carecen de funciones de lambda / primera clase (compare el enfoque de Java contra Ruby, o incluso contra el de C # "funcional", here ).
Pero creo que este argumento no niega el hecho de que los patrones de diseño existen, y que son una forma muy buena y más agnóstica de entender y describir la arquitectura de software. Eso sigue siendo válido, incluso si algunos patrones de diseño tienen implementaciones más sencillas en ciertos idiomas o son compatibles directamente con ellos.
Por supuesto, también estoy de acuerdo en que muchos patrones de diseño empresarial no cabrían en un lenguaje funcional puro. Pero también creo que el mundo funcional tiene su propio conjunto de patrones de diseño (como la Monad ).