There was a discussion on SOLID principles in the Go programming language and I threw in my two-cents. Once I was done writing, I was surprised with what I came up with.
Here is why you shouldn't think very much about SOLID in Go:
Consider each principle:
Single Responsibility Principle:
"A class should only have a single responsibility..."
Go doesn't have classes. Already the principle doesn't apply...
I write that tongue in cheek, because of course a struct is a bit like a class, and of course SRP is great for a Go struct type, but also, since Go struct types do not have inheritance, we don't get ~classes~types inheriting behaviors. Thus we don't have to worry about un-intended inherited responsibilities. It is easier to achieve SRP in Go.
Open-close Principle:
"Software entities ... should be open for extension, but closed for modification."
No inheritance, thus no extension. Go gets this for free.
Liskov substitution principle:
"Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program." See also design by contract.
Go doesn't have subtypes. YAY. So this only applies to interfaces implementations. Yes, it is an absolute must for interface implementations.
Interface segregation principle:
"Many client-specific interfaces are better than one general-purpose interface."
This is such idiomatic Go that it should go without saying.
Dependency Inversion Principle:
One should "depend upon abstractions, not concretions"
This is another way of saying accept interfaces. Yes, we value this highly in Go.
In summary:
We think about things slightly differently in Go, because Go isn't OOP, but once translated to Go's type system, SOLID absolutely matches with Go idioms.
Latest comments (7)
I'm so happy we have moved away from object orientation, that was such a mess
It would be very helpful if you went more deep than the first lines of Solid description. You dismissed so fast the SRP because of the class term, when actually the SRP is talking about module, class or function or any other programing entity, and it makes so much sense to be like this. I see a lot of Javascript developers who are writing funcțions with hundreds of lines of code doing dozens of things and makes me sad, only if they knew about this principle. And the other principles are being taken also this shallow in the article.
That was the point.
I feel like SOLID has lost much of it's relevance even for OO languages. Looking at my main language C# it is moving away from many of the classic OO patterns to something that looks a bit like Go.
That said I think you let Go off the hook too quickly on the Open-Closed principle. I don't think not having inheritance mean it doesn't apply. And you certainly do not get it "for free".
Could you give an example where the open closed principle applies in Go?
"... Robert C. Martin and others redefined the Open/Closed Principle to the Polymorphic Open/Closed Principle. It uses interfaces instead of superclasses to allow different implementations which you can easily substitute without changing the code that uses them. The interfaces are closed for modifications, and you can provide new implementations to extend the functionality of your software."
google.com/amp/s/stackify.com/soli...
Noone likes inheritance anymore :)
OK, and that is part of my point.