La información contenida en el siguiente post fue tomada de la pagina de SOLID principles Dave Cheney.
Por mi parte me encargare de realizar la traducción y dar mis comentarios al respecto, esto es un resumen de el mismo escritor original si quieren leer el documento completo los invito a visitar el link que les deje en el primer renglón.
El principio de responsabilidad única (SRP) incentiva a estructurar las funciones, tipos y métodos dentro de paquetes que exhiban una cohesión natural; lo tipos pertenecen juntos, las funciones sirven un único propósito.
El principio de Abierto/Cerrado incentiva a componer tipos simples dentro de otros mas complejos haciendo uso de "embedding".
El principio de sustitución de Liskov incentiva a expresar las dependencias entre los paquetes en términos de interfaces, tipos no concretos.Al definir interfaces pequeñas, podemos tener mas confianza en que al implementarlas cumplirán satisfactoriamente sus contratos.
El principio de sustitución de interfaces toma esta idea mas lejos e incentiva a definir funciones y métodos que solo dependan del comportamiento que necesitan. Si una función solo requiere un parámetro de un tipo interfaz con un método simple, entonces lo mas seguro que esta función solo tenga una sola responsabilidad.
El principio de inversión de dependencia incentiva a mover el conocimiento de las cosas que tu paquete dependa a partir de tiempo de compilación en Go, vemos esto con una reducción en el numero de sentencias "import" utilizadas en un paquete en tiempo de ejecución
Si quisiéramos realizar un resumen de esta platica probablemente seria; las interfaces te permiten aplicar los principios SOLID en los programas de Go
Esto es debido a que las interfaces permiten a los desarrolladores de Go describir que es lo que sus paquetes proveen, no como lo hacen. Esto es solo otra manera de hablar de "desacoplamiento", lo cual es de hecho la meta, por que el software que esta flojamente acoplado es un software fácil de cambiar.
Les dejo esto para que se vayan metiendo un poco mas a los "internals" ya que para trabajar con Golang es importante conocer todo esto, debido a su manera de trabajar la OOP hay que entenderlo como algo diferente pero enormemente funcional.
Saludos.
Now go and code around!
