Design Patterns in Go
  • Portada
  • Introducción
  • Publicación
  • Parte I
    • Sobre Go
    • POO en Go
      • Objetos
      • Herencia / Composición
      • S.O.L.I.D
  • Parte II
    • Patrones de Diseño
      • GoF
      • Patrones de Comportamiento
        • Strategy
        • Chain of Responsibility
        • Command
        • Template Method
        • Memento
        • Interpreter
        • Iterator
        • Visitor
        • State
        • Mediator
        • Observer
      • Patrones Creacionales
        • Singleton
        • Builder
        • Factory Method
        • Abstract Factory
        • Prototype
      • Patrones Estructurales
        • Composite
        • Adapter
        • Bridge
        • Proxy
        • Decorator
        • Facade
        • Flyweight
  • Parte III
    • Conclusiones
    • Acerca De
  • Recursos de interés
  • Glosario
Con tecnología de GitBook
En esta página

¿Te fue útil?

  1. Parte III

Conclusiones

AnteriorParte IIISiguienteAcerca De

Última actualización hace 5 años

¿Te fue útil?

Go es un lenguaje que en muchos aspectos parece "retrasar" o da la sensación de "antiguo". Esta visión puede ser correcta si se lo compara por ejemplo con la forma en la que programaríamos en Java. Esto es justamente lo que se debe evitar: "la comparación". Go nace con una filosofía bien clara que todo desarrollador de Go debería conocer.

Dicho esto, tal como se pudo demostrar, es factible implementar los 23 Patrones de Diseño GoF en Go sin grandes modificaciones de las estructuras originales.

Su aplicación no es una simple traducción literal de un lenguaje a otro - como he visto muchas veces - sino que el uso de estos patrones realmente pueden aportar coherencia y valor al software desarrollado en Go.

Hemos visto que Go no es realmente un lenguaje orientado a objetos, sin embargo también se pudo demostrar que sus características permiten programar aplicando prácticas y patrones propios de la programación orientada a objetos.

Dicho esto, creo que es muy importante destacar que cada lenguaje de programación nace con un propósito definido, y que si bien las experiencias previas que tenemos como desarrolladores de software nos pueden facilitar el aprendizaje de nuevos lenguajes de programación, es vital comprender cuales son las recomendaciones, usos, estilos y características propias del lenguaje que estamos aprendiendo para no cometer el error común de querer hacer las cosas de igual manera como las haríamos en otros lenguajes.

Considero que Go es un excelente lenguaje para realizar trabajos concurrentes. Este tipo de programación hace que tengamos que repensar como podemos reutilizar soluciones ante problemas conocidos. Por tal motivo, y haciendo alusión a lo antes comentado, considero que un desarrollador de Go debería invertir más tiempo en aprender como aplicar patrones de concurrencia que patrones de diseño.

Estoy seguro de que todo lo visto en esta publicación es de valor para el desarrollador de Go, pero me gustaría cerrar esta conclusión con la siguiente recomendación:

No deberían programar en Go como lo hacen en Java, PHP, C#, etc. Deberían potenciar las características propias del lenguaje en sus desarrollos; esto es comprender a fondo, por ejemplo, como funcionan las interfaces, la composición y la concurrencia; y sobre esta base reutilizar conceptos o usos de patrones de diseño cuando realmente se justifiquen.

Atención: Esta publicación se encuentra abandonada. Puede acceder a la versión vigente en

https://leanpub.com/designpatternsingo