SOLID Design Patterns in GO

[JM]

Anyone care to elaborate on how these are altered when using Go?  For example I would think that the O and the I may have to be adjusted given the way that go handles the concept of interfaces, and as far as the O, I'm guessing it still applies but might be different given the lack of inheritance and polymorphic behaviors.

Any thoughts? I'm still learning go, so just making some assumptions here at this point.

Thanks.

[Staven]

On Tue, Mar 29, 2016 at 08:26:31AM -0700, JM wrote:
> Any thoughts? I'm still learning go, so just making some assumptions here
> at this point.

While programming in Go, behave as though you've never heard of anything called "design patterns".

[John Souvestre]

> While programming in Go, behave as though you've never
> heard of anything called "design patterns".

I'm just curious. Is there anything specific to Go which makes you say this or do you feel it is true in general?

John

John Souvestre - New Orleans LA

[Miki Tebeka]

Not an expert on SOLID, but let's see:

• Single responsibility principle: This is really up to you and how you module your structs and modules. But in general Go leans toward small units that do one thing
  
• Open/closed principle: Interface and rules of what is exported help here. We use embedding instead of inhertiance.
  
• Liskov substitution principle: Interfaces again. For example fmt.Fprintf is happy as long as the first argument implements io.Writer. Case in point http.ResponseWriter
• Interface segregation principle: Small interfaces are very idiomatic Go, you can see them all over the place (see io.Writer above that has one only one function)
  
• Dependency inversion principle: Interfaces again. Many parts use interfaces and not structs. And you can use only exported fields from structs leaving the implementation details out.
  

[Egon]

On Tuesday, 29 March 2016 18:26:31 UTC+3, JM wrote:

Anyone care to elaborate on how these are altered when using Go?  For example I would think that the O and the I may have to be adjusted given the way that go handles the concept of interfaces, and as far as the O, I'm guessing it still applies but might be different given the lack of inheritance and polymorphic behaviors.

Any thoughts? I'm still learning go, so just making some assumptions here at this point.

First, they are Design Principles not Design Patterns. But it is somehow funny, that they are closer to Patterns than "GoF book".

Closest translation according to my interpretation (this doesn't necessarily mean I agree with them):

S - single responsibility: a package/type has a single important unifying idea.

O - open/closed: provide abstractions  (e.g. callbacks, interfaces)  for places of extension for module and hide internal implementation of module

L - Liskov substitution: use interfaces where there is variance in implementation

I - interface segregation: use fine-grained interfaces instead of a single big one

D - dependency inversion: depend on abstractions, not on concretions (i.e. don't depend on DB struct directly, instead use an interface for the necessary parts)

+ Egon

[Egon]

That would be ignorant. Design Patterns have a lot of good and useful stuff. Except most people only know GoF s.c. Patterns, which in reality are more idioms than they are Patterns (http://stackoverflow.com/a/24664544/192220), alternatively you might say that it's a really bad Pattern Language.

If you want to understand patterns read The Timeless Way of Building and A Pattern Language. (Or if you want the short lazy version that tries to give the essence of patterns read my post, but condensing ~1723 pages of knowledge into a single article is pretty much impossible.

+ Egon

[Egon]

Recently also stumbled upon https://vimeo.com/157708450, which was quite good video on SOLID.

[Henry]

I don't think that Go's design hinders you to do any object oriented programming if you so wish. Subclasses are just data structures with pointers to their parent classes. You can do that in Go. The only thing is that Go's syntax may be different than the syntax of other programming languages you may have used. Go's loose interface is actually a Godsend.

The only thing I find annoying with Go is that I seem to be doing a lot of copy pasting of similar codes. Perhaps it is case specific to my project, or may be I am doing it wrong. Anyhow, it does result in clearer codes and somewhat time consuming. Perhaps other gophers have different experience than I.

[JM]

Dave Cheney Solid Design Patterns in Go

https://www.youtube.com/watch?v=0IaBAl7onCE

[Michael Jones]

Indeed... the pattern language book is excellent and its topic being different is helpful to teach deep ideas away from language/programming context. 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael T. Jones
michae...@gmail.com

[Dave Cheney]

Point of order, my talk was called "SOLID Go Design", and talks about the SOLID design _principles_, not patterns. This is important.