2009-06-10 11 views
43

¿Cuán importantes son realmente los patrones de diseño?¿Qué tan importantes son realmente los patrones de diseño?

Creo que la generación anterior de programadores no usaba mucho Patrones de diseño (personas que se graduaron en los 80 y antes de mediados de los 90). ¿El recién graduado lo sabe en general y lo usa mucho más?

Si usted está interesado, también hizo una survery y se puede ver aquí:

http://www.surveymonkey.com/s.aspx?sm=kJOdGX0RPx5FGrfPVm_2bmIw_3d_3d

Actualización: Aquí están los resultados de la encuesta inicial:

http://img192.imageshack.us/img192/7107/surveyresults.png

+6

¿Puede publicar los resultados de su encuesta? Estoy interesado en los resultados –

+3

Considerando que la etiqueta "patrones de diseño" se ha utilizado en casi 1000 preguntas en SO, creo que solo puede responder a su pregunta ... o al menos una de esas muchas preguntas tiene una respuesta. – gnovice

+1

@Kwang seguro que publicaré algunos resultados. ¿Hay alguna manera de abrir los resultados también? Me gustaría abrirlo si es posible. –

Respuesta

90

Utilizamos patrones de diseño en los años 80, simplemente no sabíamos que eran patrones de diseño.

57

El mayor beneficio único de los patrones de diseño en mi opinión es que les da a los desarrolladores un vocabulario común para hablar sobre soluciones de software.

Si digo: "Debemos implementar esto utilizando el patrón singleton", tenemos un punto de referencia común para comenzar a discutir si es o no una buena idea sin tener que implementar la solución primero para saber qué Quiero decir.

Agregue en la capacidad de lectura y mantenimiento que viene con soluciones familiares a problemas comunes, en lugar de cada desarrollador tratando de resolver el problema a su manera una y otra vez.

Bastante importante. El software se puede hacer sin ellos, pero es mucho más difícil.

+11

Así que ahora tenemos a todos los desarrolladores tratando de resolver los problemas de las mismas maneras, sin importar si son apropiados. Que el ejemplo que se te ocurrió es que Singleton está diciendo: sospecho que ese patrón solo ha causado más mal diseño que todos los patrones de diseño explícitamente nombrados juntos que hayan causado un buen diseño. –

+18

Pero, ¿no te alegra que puedas decirle a la gente que no use el patrón de singleton de ciertas maneras, y ellos saben de lo que estás hablando? –

+3

El patrón Singleton puede usarse mal en muchos casos, pero considerando que la alternativa para la mayoría de las personas que lo usan es una abundancia de variables globales, creo que sería difícil culpar al mal diseño de la existencia del patrón singleton. – Gerald

38

No son absolutamente necesarios, pero los buenos definitivamente superan a los malos.

Lo bueno:

  1. la legibilidad del código: Ellos se ayudan a escribir código más comprensible con mejores nombres para lo que usted está tratando de lograr.
    • Mantenimiento de código: Permite que su código se mantenga más fácil porque es más comprensible.
    • Comunicación: Te ayudan a comunicar los objetivos de diseño entre los programadores.
    • Intención: Muestran la intención de su código instantáneamente a alguien que está aprendiendo el código.
    • Código de reutilización: Lo ayudan a identificar soluciones comunes para problemas comunes.
    • Menos código: Le permiten escribir menos código porque más de su código puede derivar una funcionalidad común de clases base comunes.
    • Soluciones probadas y de sonido: La mayoría de los patrones de diseño han sido probados, probados y sonoros.

Lo malo:

  1. niveles extra de indirección: Ellos proporcionan un nivel adicional de direccionamiento indirecto y por lo tanto hacer que el código un poco más compleja.
    • Saber cuándo usarlas: A menudo se usan mal y se usan en casos que no deberían. Una tarea simple puede no necesitar el trabajo adicional de ser resuelto usando un patrón de diseño.
    • Diferentes interpretaciones: Las personas a veces tienen interpretaciones ligeramente diferentes de los patrones de diseño. Ejemplo MVC como se ve por django vs. MVC como lo vio Ruby on Rails.
    • Singleton: ¿Necesito decir más?
+1

Estoy totalmente de acuerdo, pero su crítica (1) parece aplicarse a patrones específicos en lugar del concepto de patrones de diseño. Aunque los patrones de diseño más comunes se basan en niveles de indirección. –

+1

Tuve que reírme cuando agregaste 'Singleton'. ¡Ha sido una espina en mi costado por varios años! –

+1

:) he añadido sobre todo para el humor, pero el estado global y la restricción a sí mismo a uno solo de algo que no es una buena cosa de todos modos. –

7

importante no es la palabra que yo usaría. Usaría la palabra "útil". Proporcionar a los desarrolladores un lenguaje común para describir problemas/soluciones frecuentes es útil, más aún en un entorno colaborativo.

2

¡Buena pregunta! Me estaba haciendo esa pregunta hace una semana. Los uso siempre que puedo, pero realmente no encuentro muchas oportunidades para usarlos. Personalmente creo que la idea de Design Patterns es genial. Los ingenieros mecánicos y los ingenieros de electrónica no diseñan desde el principio, sino que aplican patrones bien entendidos que, entre otras cosas, permiten a los novatos situarse sobre los hombros del conocimiento establecido por sus predecesores. Los patrones de diseño son un paso en la dirección correcta, pero se necesitan muchos más pasos.

7

Creo que no entiende el motivo de diseño.

En la ingeniería de software, un patrón de diseño es una solución reutilizable general a un problema que se produce comúnmente en el diseño de software.

Así patrones de diseño son sólo un lenguaje formal para definir comunes formas de resolver problemas de ingeniería de software. Creo que la mayoría de la gente está usando patrones de diseño sin saber que lo son. Así que estas soluciones comunes a los problemas de software pueden tener una larga historia, simplemente no se les ocurrió un lenguaje formal para describir lo que estaban haciendo.

Creo que los patrones de diseño son importantes porque te enseñan las formas de resolver los problemas en las áreas a las que se aplican los patrones de diseño.

0

Los patrones de diseño se enseñan en clases de diseño para CS. No son esenciales, pero realmente útiles si puede encontrar situaciones análogas para tener una solución que ha sido pensada.

También permite que los programadores se comuniquen más fácilmente. También puede hablar con su compañero de trabajo en términos de los patrones. Si dice aquí que tengo mi Observer, entonces se comprende bastante bien qué está pasando.

Las personas encontrarán naturalmente soluciones que encajarán en un patrón de diseño por sí mismas, pero los patrones de diseño ayudan a definir la terminología y las ideas estándar que pueden ser útiles.

No hay nada super notable en los patrones, lo mejor es que son ideas que se canonizan y definen de maneras que son repetidamente útiles.

2

diría muy

El truco con los patrones de diseño es aprendizaje dónde y cuándo usarlos. A continuación, puede hacer todo tipo de cosas para ti como:

  1. hacer que el código sea más legible
  2. Que sea fácil de mantener
  3. hacerlo más flexible
  4. Y la lista sigue ...

pero a veces pueden hacer exactamente lo contrario de algunos de los beneficios allí una vez más su saber cómo y cuándo ...

¿Alguna vez ha intentado sacar una astilla con un martillo de enmarcar? Puede que te encante enmarcar el martillo pero va a causar todo tipo de problemas si intentas usarlo de esa manera ...

Creo que a medida que refactorizas el código, a veces evoluciona en un patrón particular o puedes tener estado usando un patrón todo el tiempo sin darme cuenta.

+2

En mi experiencia, los desarrolladores que conscientemente piensan en patrones de diseño logran los efectos opuestos con mucha más frecuencia. –

+1

Estoy de acuerdo ... Diría que escriba el código ... luego refactorítelo si es posible y si es necesario y como dije, un patrón de diseño puede evolucionar. Pero a veces durante el diseño, puede ver la oportunidad de usar uno también. – bytebender

24

Personalmente, los considero ampliamente sobrevalorado y de valor marginal. La idea suena genial, pero cuando se llega a ella, solo hay un puñado tan común y útil que vale la pena recordar (y recordar).

Diría que su efecto neto es negativo, debido a la espantosa overengineering perpetrada por las personas recién enamoradas del concepto y tratando de introducir tantos patrones en su código como sea posible. Quizás incluso peor es el efecto Maslow's hammer que conduce a un mal diseño porque en lugar de encontrar el óptimo, el desarrollador recuerda un patrón de diseño que se ajusta (mal).

+4

si las personas ejercer un juicio o seguidores es ortogonal a si los patrones de diseño son sobrevalorado y un valor marginal. La primera regla de programación es: "Piensa". Si algunas personas reemplazan esa regla con "Usar patrones de diseño" no tiene ninguna relación con la utilidad de los patrones de diseño cuando se usan en el lugar adecuado. – yfeldblum

+3

Justicia, lo siento, pero parece que no se encontró con el tipo de persona que toma el patrón de diseño kool-aid, cuyo código se ha convertido en su pesadilla de mantenimiento. Los patrones de diseño en sí mismos pueden no ser malos en las manos correctas, pero como una característica cuestionable del lenguaje de programación, invitan al abuso y, por lo tanto, son sospechosos en sí mismos. – PeterAllenWebb

+0

No ortogonal: IMO es exactamente la exageración (y el atractivo de la "idea clara") que hace que las personas sustituyan su juicio caso por caso con "usar patrones de diseño". Y parte de mi punto es que si bien el "uso apropiado" de los patrones de diseño es beneficioso, el beneficio no supera el abuso generalizado. –

1

Los patrones de software son importantes si sabes que los estás usando o no ... por definición.

Un patrón de diseño es simplemente una solución generalizada y reutilizable para un problema común.

Puede hackear hasta que reinvente la solución de cada problema que encuentre o puede aprender los "patrones" que los programadores han estado utilizando durante generaciones. Si formalizas tu conocimiento de los patrones con nombre más comunes, tendrás un vocabulario común para discutir y aplicar las soluciones.

Enjoy,

Robert C. Cartaino

6

puedo encontrar patrones de diseño de valor marginal. Cualquier marco de software bien organizado y diseñado tiene cientos de patrones de diseño, y muy pocos de ellos se describen en la "literatura de patrones" formal.

Antes de que hubiera patrones de diseño, había un software bien diseñado que tenía muchos patrones que podían reutilizarse en muchas situaciones. Por ejemplo, el libro sobre C de Kernighan y Ritchie contenía un ejemplo de una calculadora implementada usando yacc y lex y una pila, tabla de símbolos, paso de puntero a función (es decir, enlace dinámico) y contenía una gran cantidad de patrones para el tamaño del libro.

Probablemente pueda aprender cientos de patrones de diseño más útiles estudiando, p. Ej. Marco .NET de Microsoft, bibliotecas de clases Java, etc. que leyendo un libro sobre patrones de diseño.

Realmente, un buen software tiene un diseño. Y si el diseño es bueno, probablemente pueda ser reutilizado. Voila - un patrón de diseño.

7

He visto demasiados casos del síndrome de "Niño pequeño con un patrón". Por lo general, ataca con más fuerza justo después de que una persona ha leído el libro de GoF por primera vez y se escapa al instante para ver cuántos de ellos pueden encajar en el proyecto en el que están trabajando. (Puntos adicionales para incluir a los 23 en un solo proyecto). Terminan con un sistema que está diseñado a una pulgada de su vida e imposible de entender o modificar.

Eventualmente la fiebre se rompe y se calman lo suficiente como para usarlos apropiadamente. Pero el daño puede ser genial.

La historia de advertencia es el libro "Core Java EE Patterns". Enumera una serie de cosas que abordan las "mejores prácticas" para EJB 1.0 y 2.0 que ahora se consideran antipatrones. La especificación EJB 3.0 elimina muchos de ellos. La primavera está matando al resto.

Los patrones han tenido su día en el sol, como UML. Pero el sol está bajando en ambos. No creo que ninguno haya salvado el mundo ni haya sido entregado al bombo.

5

Si bien puede ser útil hablar sobre los patrones de diseño a veces, tiendo a estar de acuerdo con aquellos que los consideran dañinos en muchas situaciones.

El argumento principal que quisiera hacer es que a menudo impiden que las personas encuentren las soluciones adecuadas para un problema específico. En lugar de pensar en cómo resolver ese problema en particular, las personas intentan aplicar un patrón de diseño después del otro.

También tienden a ocultar las deficiencias del lenguaje. Muchos de ellos son triviales en un lenguaje lo suficientemente expresivo. Un buen ejemplo sería el patrón de estrategia, que básicamente consiste en reinventar la programación funcional de una manera complicada. A menudo las personas estarían mejor entendiendo los principios de programación reales en lugar de simplemente hablar idiomas de patrones.

Dicho esto: prefiero hablar de patrones con alguien que no tener un lenguaje en absoluto. De esa forma, son importantes si no hay una mejor opción. Si puedo explicarme de forma más formal (por ejemplo, álgebras), entonces dejo de preocuparme por los lenguajes de patrones. Por supuesto, algunos afirmarían que simplemente inventé mis propios lenguajes de patrones de esa manera ;-)

2

Yo diría que definitivamente son importantes.

Entre las razones típicas (vocabulario compartido, no reinventar la rueda) son un trampolín para aprender un buen diseño de software. La mayoría de los patrones de diseño comienzan por los programadores con un buen sentido de los principios OO aplicando lo que saben para resolver un problema, y ​​notando que otras personas tienen la misma solución. Si piensas en los patrones de diseño como un libro de cocina para resolver el problema actual en el que estás atrapado, no son realmente útiles, y es aquí donde ves aparecer el "patrón de diseño de martillo" y complicar los diseños.

Si en lugar de pensar en ella como una ventana al buen diseño orientado a objetos, comienza a ver lo valiosos que son, es decir, pensar en términos de los principios detrás de los patrones de diseño en lugar de los patrones de diseño específicos.

1

Comience con los principios antes de considerar los patrones, porque son los principios de diseño generales los que informan y motivan la aparición de patrones.

Para su problema en particular, lo mejor es seguir los principios primero y más importante. Si llega a un Patrón bien conocido, enhorabuena, acaba de redescubrir un Patrón, bueno para usted. El problema es que puede llevarte mucho tiempo, por lo que depende si quieres arriesgarte a inventar algunos antipatrones en el camino o si quieres un atajo a algo que ya ha sido publicado. Sin embargo, considéralo, porque aprenderás más que leer la descripción de otra persona de su propio trabajo.

El lado negativo (como muchas de las muy buenas respuestas aquí ya han señalado) es que podría tener la tentación de aplicar un patrón publicado en un contexto en el que no se ajusta o simplemente no está garantizado.

Un buen lugar para comenzar con los Principios de diseño es examinado Uncle Bob Martin's SOLID principles, lo bueno de ellos, una vez que se hunden en el, es que se siente como que ya los conocía (que te hace sentir inteligente) y

El libro de tío Bob Clean Code también cubre muchos de los mismos principios con algunos ejemplos útiles, solo que no menciona explícitamente los principios como los artículos originales, se enfoca más en organizar y ordenar sus funciones, clases, etc.

0

Comentó Design Patterns son útiles si intenta contribuir con proyectos de código abierto ... ¡ya dijimos!

Cuestiones relacionadas