2 ms·
I don't see how. Golang has first class support for bundling state and behavior: Receiver-Functions, often called methods. This means exactly 2 things; a) That
by usrbinbash 3y ago
I don't see how.
Golang has first class support for bundling state and behavior: Receiver-Functions, often called methods. This means exactly 2 things; a) That for a type `Foo` I can do this:
f := Foo{}
f.funcThatUsesFoo()
instead of this:
f := Foo()
funcThatTakesFooAsFirstArgument(f)
and b) that Foo implements all interfaces whos method signatures it's receiver functions satisfy.
It doesn't mean that I now have to suddenly drown my code in over-architectured patterns just to satisfy some OOP sense of code-aesthetic. It doesn't mean that I have to try and hide state from code in the same module. It doesn't mean that I have to bundle things that could be free-standing functions into some type just because. It doesn't mean I have to make any of the mistakes OOP popularized over the years.