This post is part of a series where I do my best to organize my thoughts around Go: its paradigms and usability as a programming language. I write this as a Java programmer that respects the principles of Elegant Objects.
In a previous post I attempted to implement Elegant container-like idioms in Go. My approach was straightforward: follow the same train of thoughts I do in Java. I failed miserably.
Following is an approach I find interesting.
Let’s use Functions
Let’s ditch interfaces altogether and define our Products
type as a function. I’ve managed to earn back two features of the Java counterpart:
- Actual decorators
- Deferred execution
However, I’ve only managed to work it out for query capabilities. Our Products
is still a castrated object because it lacks smart capabilities as per point #3 in the previous post.
Conclusion
A bit early to actually reach a conclusion but this design further encourages me to believe that Go is a lot more oriented towards functional programming than object-oriented programming. Almost to the pointing of making me question what net value do interfaces in this language provide?