No puedo entender los patrones de diseño de programación

16

He estado trabajando con JavaScript durante los últimos 4 años. Tengo mucha confianza en mis habilidades para resolver problemas y puedo ver que la calidad de mi código está mejorando. Intento mantenerme al día con la comunidad y actualmente estoy trabajando con ES2015 y React.js. Sin embargo, siento que no puedo comprender los patrones de diseño de programación. Sé dónde encontrar recursos sobre esto y ya he leído libros al respecto. Confío en mis compañeros de trabajo para tomar decisiones sobre la estructura del proyecto, pero no tengo problemas para trabajar en ello.

Siempre que necesito comenzar algo por mi cuenta, busco estos dos caminos: si estoy usando una gran biblioteca / marco como React.js, tiendo a copiar lo que está haciendo la comunidad; Si estoy en algo más pequeño, usaré el patrón del módulo. Sé que una vez que comprenda mejor este tema, podré tomar mejores decisiones, pero por ahora estoy completamente perdido.

¿Debo buscar una educación superior en esto? ¿Necesito un mentor en este tema? ¿Soy simplemente estúpido? ¿Es realmente tan difícil de entender?

design-patterns javascript

— Abensur
fuente

66

En mi opinión, algunos lenguajes son más "indulgentes" que otros cuando se trata de la necesidad de usar patrones de diseño. Los lenguajes compilados fuertemente tipados (como Java y C #) se ven más afectados por un mal diseño que los lenguajes de secuencias de comandos débilmente tipados como JavaScript y PHP. No quiere decir que los patrones de diseño no sean útiles para ambos, por supuesto.

— Mateo

3

El tamaño del proyecto también juega un papel importante también.

— Mateo

2

@Matthew nitpick No necesariamente llamaría Java / C # fuertemente tipado ...

— Jared Smith

2

@JaredSmith es cierto, a menudo olvido la distinción entre tipado fuerte y tipeado estático.

— Matthew

66

Si estás tratando de entender y patrones en general , ¡para! ¡No hay nada allí! Un patrón es una solución popular a un problema que ocurre comúnmente, y alguien le dio un nombre. Eso es todo al respecto. Es posible que le resulte difícil captar algún patrón específico : yo mismo lucho para recordar cómo usar efectivamente el patrón de "visitante" para imitar el envío dual en Java, pero si está buscando la salsa secreta que une al "visitante" para decir "objeto de transferencia de datos", no lo encontrará. Son solo dos soluciones populares para dos problemas comunes, alguien les dio nombres y los nombres se quedaron.

— Solomon Slow

34

Los patrones de diseño de software son soluciones bien conocidas para problemas bien conocidos. La forma en que los comprende es aprendiendo los patrones, entendiendo cómo funcionan y sabiendo cuándo es apropiado aplicar cada uno a su diseño de software.

La forma de aprender patrones de diseño de software es estudiándolos, uno a la vez. Es un proceso de educación continua. Si desea reducir la huella de aprendizaje, estudie los patrones que se relacionan directamente con las tecnologías que está utilizando actualmente.

Algunas cosas importantes que debe saber sobre los patrones de diseño:

Algunos patrones de diseño son de naturaleza arquitectónica. MVC y MVVM son ejemplos de tales patrones. Utiliza dichos patrones cuando necesita los beneficios organizativos y estructurales que proporcionan.
Algunos patrones de diseño son soluciones para las deficiencias en los lenguajes de programación. No necesitará estos patrones si usa un lenguaje de programación más expresivo, pero a menudo no puede hacer esta elección. La mayoría de los patrones de GoF son en esta categoría .
Use un patrón de software solo cuando intente resolver el problema que el patrón está específicamente diseñado para resolver. Si está escribiendo una aplicación uniendo patrones de software, lo está haciendo mal.
No existe un patrón de software existente para todos los problemas informáticos existentes. Si ese fuera el caso, la programación sería simplemente un ejercicio de coincidencia de patrones.
Algunos patrones son en realidad antipatrones. La complejidad adicional que introducen estos patrones supera los beneficios que proporcionan. Tendrás que decidir por ti mismo, patrón por patrón, cuál de estos patrones evitarás.

— Robert Harvey
fuente

Buena respuesta, aunque no estoy de acuerdo con la afirmación de que la mayoría de los patrones de GoF son una solución para las deficiencias en los lenguajes de programación. A menudo, algunos patrones se aplican mejor a ciertos idiomas, sí, porque los idiomas tienden a diseñarse teniendo en cuenta ciertos problemas y soluciones.

— Polygnome

1

Los patrones de Gof tienen 20 años. La mayoría de ellos fueron creados para solucionar problemas con C ++, problemas que Java heredó porque Java se basa en C ++.

— Robert Harvey

La paradoja en esta respuesta es la parte del "problema bien conocido". Es difícil entender estos "problemas bien conocidos" si nunca los ha experimentado.

— Fuhrmanator

2

Java no está basado en C ++. La sintaxis de Java está inspirada en C ++, pero ciertamente no se basa en ella. ambos idiomas funcionan de manera bastante diferente. Por el hecho de que Java abstact hardware, gestiona la memoria por sí mismo, sobre no tener plantillas, sino genéricos, etc.

— Polygnome

4

El enfoque de aprendizaje de cada persona es un poco diferente, y no tengo idea de cuál es su enfoque general, pero sí creo que se está perjudicando al etiquetarse como "estúpido".

Personalmente, según mis observaciones de lo que muchos llamarían ingenieros de software "exitosos", diseñadores, etc., todos tienen un tema común para su aprendizaje: "experiencia". Creo que esta es su "educación superior" y aprenderá más rápidamente de ella que comprar toneladas de libros en Amazon y leerlos (un mal hábito mío).

Entonces, por ejemplo, tome un patrón GOF como el patrón de comando e impleméntelo en el idioma que elija. Comprenda los beneficios que le brinda a usted y los inconvenientes. Los diversos libros sobre patrones de diseño te explicarán esto, pero creo que es mejor aplicar ese conocimiento prácticamente y aprender de él. No descarte el material de lectura, tienen un propósito, pero el mundo de TI difícilmente es un ejercicio de libro de texto. Dicho esto, esa es mi opinión y visión del mundo de TI y, en parte, representa luchas propias al comenzar mi carrera en ingeniería de software. Además, veo un problema importante, incluso con desarrolladores de software con mucha experiencia es la impaciencia y el olvido de disfrutar lo que están haciendo. Así que tómese su tiempo con lo que está aprendiendo y recuerde disfrutar realmente de lo que está haciendo, de lo contrario, ¿por qué molestarse en invertir tiempo en ello?

Además, aproveche la experiencia práctica de otras personas. Hay una gran cantidad de soluciones de código abierto, tanto buenas como malas, y puede aprender de ellas. Mire cómo han aplicado patrones y piense cómo lo abordaría de manera diferente.

Entonces, mi consejo general es que si siente que su enfoque es incorrecto, cámbielo. Mire a las personas a su alrededor que siente que está aprendiendo el material que siente que no está comprendiendo y observe lo que están haciendo o incluso pregúnteles.

— Planeta desolado
fuente

1

Realmente creo que la programación es como el juego de ajedrez. Es posible que tenga algo de talento nativo, puede jugarlo todo el día, pero si no lee algunos libros sobre ajedrez, no puede avanzar y, lo que es más importante, no puede apreciar la belleza del juego.

— Adrian Iftode

@AdrianIftode - de acuerdo. Como se mencionó, no descartaría libros, blogs o cualquier material de lectura, pero es un problema común que he encontrado con personas que se esfuerzan por dominar un lenguaje de programación / plataforma / marco, etc. y aparentemente han hecho poca codificación y / o práctica esfuerzo, pero he leído todos los libros en los que puedes sacudir un palo.

— Desolate Planet

@AdrianIftode Bueno, no precisamente. Jugando al ajedrez sin leer libros, aún puedes aprender mucho sobre el juego. La única diferencia es que no estás aprendiendo tan rápido como podrías al recurrir a algunas experiencias y pensamientos de maestros de ajedrez. Por otro lado, al pensar en ciertas cosas, puede tropezar con una solución o dos que las personas que solo aprenden de los maestros de ajedrez han ignorado por completo y que puede utilizar para su ventaja. Al final, creo que una combinación de ambos tipos de aprendizaje proporciona el mejor beneficio. Tanto en ajedrez como en programación.

— cmaster - reinstalar monica

1

La respuesta corta es que no necesitas . Puedes escribir código sin ellos. Como dijo Matthew en los comentarios, esto es particularmente cierto en JavaScript, donde el lenguaje es bastante flexible y los proyectos tienden a ser más pequeños. Pero si ha estado programando durante 4 años, me resulta difícil creer que no haya tropezado con cosas que se sienten repetitivas o incómodas. Son esas áreas que estás redescubriendo o faltan patrones de diseño.

Ejemplo: el sistema de eventos de JavaScript a menudo es inadecuado para la tarea en cuestión. ¿Nunca te encuentras con ganas de poder combinar o transformar flujos de eventos? ¿O esa serie de eventos fueron valores de primera clase por derecho propio? Necesita los patrones de mediador y / u observador. ¿Necesita enlace de datos bidireccional? La misma historia

¿La frágil jerarquía del prototipo se cayó? Mezcla / Rasgo / Subclase Patrones de fábrica al rescate.

— Jared Smith
fuente

44

Es prácticamente imposible escribir un programa no trivial sin usar ningún patrón de diseño, por lo general, también usarás muchos comunes. Lo que no necesita es poder reconocer los patrones que está utilizando por nombre. Puede escribir código de trabajo incluso si no puede nombrar todos los patrones de diseño que está utilizando en todo el código.

— Servy

Los patrones de @Servy Design son abstracciones, las abstracciones no son estrictamente necesarias. Siempre puede escribir una implementación puntual ad hoc del comportamiento subyacente ... una y otra y otra vez. Por ejemplo, en el ejemplo que di sobre eventos, es posible conectar manualmente a todas las partes interesadas y luego cambiarlas todas cada vez que cambian los requisitos, simplemente apesta en comparación con el uso de pub / sub. Para las subclases es posible (si es un desperdicio) codificar manualmente en cada posibilidad con un montón de clases únicas, simplemente no es tan bueno.

— Jared Smith

1

Los patrones de diseño pueden ser muy amplios. A menudo, los patrones de diseño más amplios son tan obvios que ni siquiera pensamos en ellos como patrones de diseño (especialmente cuando tienen soporte de lenguaje especial). Un bucle es un patrón de diseño. Las funciones son un patrón de diseño. Los objetos son un patrón de diseño.

— Servy

@Servy si así es como estás usando el término, entonces no estoy en desacuerdo, pero tuve la impresión de que el OP se refería específicamente a los patrones GOFish.

— Jared Smith

1

Los patrones de diseño de @JaredSmith no son abstracciones. Incluso si los implementa una y otra vez para el problema concreto que tiene, siguen siendo patrones . No necesita escribir una clase de Observador genérica y usarla para usar el patrón Observador . Escribir observadores concretos y métodos concretos para registrarlos y notificarlos todavía está usando el patrón. Lo difícil es reconocer el patrón. A veces se utiliza un patrón sin siquiera saber su nombre,

— Polygnome

1

Encuentre un mentor, alguien con muy buena experiencia para aprender. Hágale preguntas, mire su código, envíe una revisión de código e intente colaborar con él. Esta es la mejor manera de intensificar sus habilidades de codificación.

extra:

Colabora en algún proyecto simple de OSS que te guste
Cuando hay dos formas de resolver el mismo problema, elija siempre la más simple
Desarrolle algo de experiencia adicional con proyectos paralelos en los que es libre de cometer todo tipo de errores extraños, y aprenderá el patrón de diseño "a la fuerza" (tm)

— Motocarota
fuente