Patrones de Diseño: ¿Necesarios o "parcialmente" irrelevantes?

[kub0x]

Ha existido mucho criticismo desde que en 1994 se publicó el libro de Design Patterns el cual introduce numerosos patrones que intentar extender la funcionalidad de los lenguajes de la programación.

Me gustaría saber que opinaís aquellos que como un servidor, llevaís muchos años en esto. Sé que se pueden prescindir de éstos, por ejemplo, creando tu propia funcionalidad para lo que necesites. También se comenta que los lenguajes a medida que avanzan (JDK, estandar C++, .NET Framework...) también introducen sus propia forma de solventar la funcionalidad que no proveían anteriormente, eliminando el uso de patrones por parte del programador.

La pregunta sería, Patrones de Diseño: ¿Necesarios o "parcialmente" irrelevantes?

Saludos.

[FFernandez]

un programa con muchas líneas de código si no se sigue un patrón, en caso de falla ¿¿?¿
A la hora de actualizar el programa por motivos varios,  "compatibilidad" etc..?¿?¿
La semejanza en los patrones de objetos, funciones, etc..  en distintos lenguajes, nos ayudan a migrar de uno a otro con relativa facilidad...............

[kub0x]

un programa con muchas líneas de código si no se sigue un patrón, en caso de falla ¿¿?¿
A la hora de actualizar el programa por motivos varios,  "compatibilidad" etc..?¿?¿
La semejanza en los patrones de objetos, funciones, etc..  en distintos lenguajes, nos ayudan a migrar de uno a otro con relativa facilidad...............

Ante todo, gracias por responder, una respuesta escueta, pero se agradece.

Sin embargo, cuando un proyecto no es gigantesco y el mismo se basa en la OOP (orientación a obj), resulta que con un buen diseño de clases los patrones típicos como composite, factory, adapter, observer, etc son innecesarios.

El programador tendrá un control absoluto de la funcionalidad y no tendrá que aplicar éstos en su diseño. De hecho el propio lenguaje permite al usuario aplicar templates o heredar/implementar interfaces (clases abstractas) cuya finalidad es simplificar el trabajo del programador.

[@XSStringManolo]

Siempre pueden ser útiles. Yo creo que cada uno vamos haciendo nuestros propios dentro de nuestra cabeza.

Como bien dices estos patrones suelen acabar formando parte de la implementación de funciones nativas del lenguaje. Solo este echo, destaca la utilidad de los patrones de diseño, que suelen ir enfocados a resolver problemas comunes de una forma extrapolable entre lenguajes.

Qué muchos se incluyan en el lenguaje no quita que existan muchos otros que están bien estudiados y son la mejor solución a un problema concreto. 

Aún ayer hice spam del patron de iterador para leer datos de un stream tcp, de archivos... En python no vi la forma de utilizarla y me vi negro para resolver un problema.

Código (javascript) [Seleccionar] Expandir

let request = "", r;
  while ((r = std.in.getline()) != "\r") {
    request += r + "\n";
  }

console.log(`Request:
${request}`);

Yo creo que aprender a implementar un patrón en un lenguaje te quita de tener que proveer una solución improvisada cada vez que te encuentres con el mismo problema. Qué presumiblemente va a tener pequeñas diferencias que pueden romper la integridad y dificultar el código.

Al final si programas bien es probable que los uses sin darte cuenta, porque suelen ser la mejor solución a problemas comunes.

[kub0x]

Gracias por tu respuesta Manolo.

Es bien cierto que sin utilizarlos no podemos aplicar ciertas funcionalidades.

Tu ejemplo del iterador es bien claro y es algo que CPP NET y Java como ya sabes implementan.

La pregunta la realice porque vi en stackover que los patrones deberían escribirse en todo tu desarrollo para agilizar pero hay mucha gente en contra como si de escribir una macro gigante se tratara y en cierto modo estoy de acuerdo ya que va en función de lo que necesites resolver. De ahí lo de parcialmente irrelevantes.

Saludos.

[@XSStringManolo]

Gracias por tu respuesta Manolo.

Es bien cierto que sin utilizarlos no podemos aplicar ciertas funcionalidades.

Tu ejemplo del iterador es bien claro y es algo que CPP NET y Java como ya sabes implementan.

La pregunta la realice porque vi en stackover que los patrones deberían escribirse en todo tu desarrollo para agilizar pero hay mucha gente en contra como si de escribir una macro gigante se tratara y en cierto modo estoy de acuerdo ya que va en función de lo que necesites resolver. De ahí lo de parcialmente irrelevantes.

Saludos.

Yo estoy en desacuerdo porque es una herraminta opcional, no obligatoria. Por tanto, depende plenamente de la habilidad y la capacidad de evaluación del desarrollador su uso.

Es una llave inglesa buena o mala? -La llave inglesa es mala porque dobla al levantar un motor. XD

[ThunderCls]

La respuesta a tu pregunta es subjetiva. El uso de patrones de diseño no necesariamente influiran de forma substancial en el rendimiento del codigo final (en el 99% de los casos), por lo que del punto de vista de una posible ganancia en rendimiento me atreveria a decir que son "irrelevantes". Por otra parte, los patrones de diseño tienen muchas otras ventajas. No solo, estandarizan el codigo, pero hacen que puedas seguir buenas practicas, permiten la reusabilidad de tu codigo, etc. En este sentido si te dedicas a trabajar profesionalmente a desarrollar software, es muy probable que el jefe de proyecto te requiera codigo que pueda ser facilmente mantenido y entendido por el resto del equipo aun si el autor original no esta (Low Coupling, High Cohesion principle), por lo que si, en un ambiente profesional los patrones de diseño son altamente recomendados y/o necesarios.
Algunos de estos patrones, como has mencionado, han sido implementados como estandares en varios "lenguages modernos" como por ejemplo el patron MVC (Model-View-Controller) en .NET

Saludos

[Serapis]

Coincido en lo de parcialmente irrelevante.

Sin duda cuando un sistema es complejo, disponer de una plantilla que l resuleva es eficiente en cuanto al tiempo de desarrollo, sin embargo las soluciones suelen tener peor eficiencia en cuanto a ejecución. Dado que en orden a la claridad y orden, las cosas pueden estar duplicadas no estar alojadas en el sitio más favorable etc... a menudo hay clases intermedias ocultas, precisamente para empaquetar funcionalidad, pero que estrictamente no serían necesarias, pero suponen una simplificación sobre el control del código.

Es irrelevante, porque cuando se conoce y tiene claro lo que se precisa hacer se puede hacer más eficiente sin seguir el patrón con 'total exactitud', de hecho hay cosas que ni necesitas o no incluye otras que precisas como fundamentales, luego usar un patrón de sieño, puede suponer tener que 'bordearlo' para que se ajuste a lo que quieres, con lo que ya se sale aún más de la eficiencia (sucede con todo ese código necesario para circundar las limitaciones que el sistema impone).

No es irrelevante para programadores que se manejan en el fangoso mar de las dudas, tampoco para quienes precisan un código rápido  (de escribir, no de ejecución).

Por otro lado, si uno se pone al caso habría tantos 'semipatrones' de diseño que no bastarían una docena de libros para describirlos.

Finalmente diría, que mucha de la filosofía de un lenguaje conlleva tras de sí, precisamente ciertos patrones no visibles.... después de todo, el propio paradigam de la programación orientada a objetos, nació como un patrón de diseño, aunque ya desde los 70 y 80, se auguraba más o menos vagamente dicho paradigma aunque sin concesiones, por entonces la pralabra 'estructurado' era el clímax del que hoy sale ese apéndice que entendemos como patrones de diseño.