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
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
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

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 8 | next ›
Discussion Overview
groupgolang-nuts @
postedMar 29, '16 at 3:26p
activeMar 30, '16 at 10:55a



site design / logo © 2021 Grokbase