Does idiomatic way to code in go encourage oop practices

I know, go is all about type and values. There are no class and inheritance for good.Recently, In production, I have implemented a feature using factory and strategy patterns(In a oops way)
Just wanted to know, have I over engineered or am i abusing the idiomatic go practices ?

Less than other more oop centric languages, but it does encourage oop practices. Polymorphism and inheritance seem to be backed by the language the same as in C++ or Java.

Encapsulation and abstraction are the 2 traits that look like they’re not directly enforced. However, I am pleasantly surprised to read about pipelines and concurrency patterns - they do force developers to actively use encapsulation and abstraction - although in a somewhat different way.

is it okay to use all the oops design patterns in go like a factory pattern to create instance of structs ?

Sure, I do not see why not.

However, make sure you use multiple goroutines to split your work between multiple processors - this is the main advantage of go.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.