language agnostic - ¿Utiliza patrones de diseño?
language-agnostic design-patterns (15)
En mi opinión, la pregunta: "¿Usas patrón de diseño?", Solo es un poco defectuoso porque la respuesta es universalmente SÍ.
Permítanme explicar, nosotros, programadores y diseñadores, todos usamos patrones de diseño ... simplemente no siempre nos damos cuenta. Sé que esto suena a cliché, pero no vas a patrones, los patrones vienen a ti. Usted diseña cosas, podría parecerse a un patrón existente, así lo llama para que todos entiendan de lo que está hablando y la razón detrás de su decisión de diseño es más sólida, sabiendo que se ha discutido antes.
Yo personalmente uso patrones como una herramienta de comunicación. Eso es. No son soluciones de diseño, no son mejores prácticas, no son herramientas en una caja de herramientas.
No me malinterprete, si es un principiante, los libros sobre patrones le mostrarán cómo una solución se resuelve mejor "usando" sus patrones en lugar de otro diseño defectuoso. Probablemente aprenderá del ejercicio. Sin embargo, debes darte cuenta de que esto no significa que cada situación necesita un patrón correspondiente para resolverlo. Cada situación tiene un capricho aquí y allá que requerirá que pienses en alternativas y tomes una decisión difícil sin una respuesta perfecta. Eso es diseño.
Anti-patrón, sin embargo, están en una clase totalmente diferente. En realidad, quiere evitar activamente los antipatrones. Es por eso que el nombre anti-patrón es tan controvertido.
Para volver a su pregunta original:
"¿Uso patrones de diseño?", ¡Sí!
"¿Me inclino activamente hacia los patrones de diseño?", No.
¿Cuál es la penetración de los patrones de diseño en el mundo real? ¿Los usas en tu trabajo diario -discutiendo cómo y dónde aplicarlos con tus compañeros de trabajo- o siguen siendo más un concepto académico?
¿Realmente le proporcionan valor real a su trabajo? ¿O son simplemente algo de lo que la gente habla para sonar inteligente?
Nota: Para los fines de esta pregunta, ignore los patrones de diseño ''simples'' como Singleton . Estoy hablando de diseñar tu código para que puedas aprovechar el Controlador de Vista de Modelo , etc.
Encuentro que el patrón MVC es realmente útil para aislar la lógica de su modelo, que luego puede reutilizarse o procesarse sin demasiados problemas. También ayuda a desconectar las clases y facilita las pruebas unitarias. Escribí sobre esto recientemente (sí, el enchufe descarado aquí ...)
Además, recientemente utilicé un patrón de fábrica de una clase base para generar y devolver la clase DataContext adecuada que necesitaba sobre la marcha, utilizando LINQ .
Los puentes se usan cuando se trata de unir dos tecnologías diferentes (como Cocoa y Ruby en la Mac, por ejemplo)
Sin embargo, encuentro que cada vez que implemento un patrón, es porque lo sabía de antemano. Por lo general, tengo que pensar un poco más ya que creo que debo modificar el patrón original ligeramente para adaptarlo a mis necesidades.
¡Solo debes tener cuidado de no convertirte en astronauta de arquitectura !
Hay muchos patrones de diseño más allá de lo simple que se usan en el "mundo real". Buen ejemplo utiliza el patrón de controlador de vista de modelo. He usado las fábricas de clase varias veces en proyectos para mi empleador, y también he visto muchos proyectos ya escritos usarlos.
No digo que se estén utilizando todos los patrones de diseño, pero muchos sí lo están.
Intento usar patrones si son aplicables. Creo que es un poco triste ver a los desarrolladores implementar patrones de diseño en el código por el simple hecho de hacerlo. Sin embargo, para la tarea correcta, los patrones de diseño pueden ser muy útiles y poderosos.
Intento, sí. Ciertamente ayudan a mantener y a leer su código. Sin embargo, hay personas que abusan de ellos, generalmente (por lo que he visto) forzando a un sistema a un patrón que no existe.
MVC es muy conocido, así que sí, usamos patrones de diseño bastante. Ahora, si preguntas sobre los patrones de la Banda de los Cuatro, hay varios que utilizo porque otros mantenedores sabrán el diseño y para qué trabajamos en el código. Sin embargo, hay varios que permanecen bastante oscuros para lo que hacemos, así que si uso uno no obtengo todos los beneficios de usar un patrón.
¿Son importantes? Sí, porque te da un método para hablar sobre el diseño de software de manera rápida, eficiente y generalmente aceptada. ¿Puedes hacer mejores soluciones personalizadas, bueno sí (sorta)?
Los patrones originales de GoF se extrajeron del código de producción, por lo que catalogaron lo que ya se estaba utilizando en la naturaleza. No son puramente o incluso mayormente una cosa académica.
Sí, Factory, Chain of Responsibility, Command, Proxy, Visitor y Observer, entre otros, están en uso en una base de código con la que trabajo a diario. En cuanto a MVC, este sitio parece usarlo bastante bien, y los desarrolladores no pudieron decir suficientes cosas buenas en el último podcast .
Sí, lo hacemos, generalmente sucede cuando comenzamos a diseñar algo y luego alguien se da cuenta de que se asemeja a un patrón existente. Luego lo miramos y vemos cómo nos ayudaría a lograr nuestro objetivo.
También utilizamos patrones que no están documentados, pero que surgen del diseño de un lote.
Eso sí, no los usamos mucho.
Sí, utilizo muchos patrones de diseño bien conocidos, pero también terminé construyendo algún software que luego descubrí que usa un patrón de diseño ''nombrado''. La mayoría de los diseños elegantes y reutilizables podrían llamarse ''patrón''. Es muy parecido a los movimientos de baile. Todos conocemos el vals y el de 2 pasos, pero no todos tienen un nombre para el ''bache y el patinazo'', aunque la mayoría de nosotros lo hacemos.
Yo uso absolutamente patrones de diseño. En este punto, tomo MVC por sentado como un patrón de diseño. Mi principal razón para usarlos es que soy lo suficientemente humilde como para saber que probablemente no sea la primera persona que encuentre un problema en particular. Raramente comienzo un código sabiendo qué patrón voy a usar; Miro constantemente el código para ver si se desarrolla naturalmente en un patrón existente.
También me gustan mucho los Patrones de arquitectura de aplicaciones empresariales de Martin Fowler . Cuando se presenta un problema o tarea, cambio a la sección relacionada (es principalmente un libro de referencia) y leo algunas descripciones generales de los patrones. Una vez que tenga una mejor idea del problema general y de las soluciones existentes, comenzaré a ver el camino a largo plazo que mi código probablemente tomará a través de la experiencia de los demás. Termino tomando mejores decisiones.
Los patrones de diseño definitivamente juegan un papel importante en todas mis ideas "para el futuro".
Cualquier programa grande que esté bien escrito usará patrones de diseño, incluso si no son nombrados o reconocidos como tales. Eso es lo que son los patrones de diseño, diseños que ocurren repetida y naturalmente . Si estás interactuando con una API fea, probablemente te encuentres implementando una Facade para limpiarla. Si tiene mensajes entre componentes que necesita desacoplar, puede encontrarse usando Observer . Si tiene varios algoritmos intercambiables, puede terminar usando Strategy .
Vale la pena conocer los patrones de diseño porque es más probable que los reconozcas y luego converjas en una solución limpia más rápidamente. Sin embargo, incluso si no los conoces del todo, terminarás creándolos eventualmente (si eres un programador decente).
Y, por supuesto, si usa un lenguaje moderno, probablemente se vea obligado a usarlo para algunas cosas, ya que están integradas en las bibliotecas estándar.
Sí, los patrones de diseño se utilizan en gran parte en el mundo real, y diariamente por muchas de las personas con las que trabajo.
En mi opinión, el mayor valor que brindan los patrones de diseño es que proporcionan un lenguaje universal de alto nivel para transmitir el diseño de software a otros programadores.
Por ejemplo, en lugar de describir tu nueva clase como una "utilidad que crea una de varias clases basadas en una combinación de criterios de entrada", simplemente puedes decir que es una "fábrica abstracta" y todos comprenden instantáneamente de lo que estás hablando.
Sí, los patrones de diseño o los patrones abstractos son parte de mi vida, donde miro, comienzo a verlos. Por lo tanto, estoy rodeado de ellos. Pero, como sabes, poco conocimiento es algo peligroso. Por lo tanto, le recomiendo leer el libro GoF.
Uno de los principales problemas sobre los patrones de diseño es que la mayoría de los desarrolladores simplemente no entienden la idea o no creen en ella. Y la mayoría de las veces discuten sobre las variables, bucles o interruptores. Pero, creo firmemente que si no habla el lenguaje de patrones, su software no llegará muy lejos y se encontrarán en una pesadilla de mantenimiento.
Como usted sabe, el antipatrón es también algo peligroso y ocurre cuando tiene poca experiencia en patrones de diseño. Y la refactorización de antipatrones es mucho más difícil. Como libro recomendado sobre este problema, lea "AntiPatrones: software de refactorización, arquitecturas y proyectos en crisis".
Sí. Los patrones de diseño pueden ser maravillosos si se usan apropiadamente. Como mencionaste, ahora estoy usando Model-View-Controller (MVC) para todos mis proyectos web. Es un patrón muy común en el espacio web que hace que el código del servidor sea mucho más limpio y bien organizado.
Más allá de eso, aquí hay algunos otros patrones que pueden ser útiles:
MVVM (Model-View-ViewModel): un patrón similar a MVC; utilizado para aplicaciones WPF y Silverlight.
Composición: ideal para cuando necesita usar una jerarquía de objetos.
Singleton: más elegante que usar globales para almacenar elementos que realmente necesitan una sola instancia. Como mencionaste, un patrón simple pero tiene sus usos.
Vale la pena señalar que un patrón de diseño también puede resaltar la falta de características de lenguaje y / o deficiencias en un idioma. Por ejemplo, los iteradores ahora están integrados como parte de los idiomas más nuevos.
En general, los patrones de diseño son bastante útiles, pero no debe usarlos en todas partes; justo donde son adecuados para sus necesidades.
Sí.
Incluso los estamos usando en mi trabajo actual: codificación de mainframe con COBOL y PL / I.
Hasta ahora he visto Adapter, Visitor, Facade, Module, Observer y algo muy parecido a Composite e Iterator. Debido a la naturaleza de los idiomas, se utilizan principalmente patrones estruturales. Además, no estoy seguro de que las personas que los usan lo hagan conscientemente: D