Sometimes I read an article that says “Go is object oriented”. Sometimes another article that claims that no object oriented programming can be done with Go, just because it does not have classes.
So I wrote this post to clarify this topic. Is Go object oriented, or not?
Yes, Go is object oriented. Here is what GO FAQ says:
Yes and no. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, even built-in types such as plain, “unboxed” integers. They are not restricted to structs (classes).
Also, the lack of a type hierarchy makes “objects” in Go feel much more lightweight than in languages such as C++ or Java.
Go picked some concepts from functional programming and object oriented programming, and put them together, and left out other concepts to create its own unique flavor of idiomatic programming style. So it did a cherry picking on concepts.
There are no classes in Go however there are structs in Go which are powerful than in C. Here the struct type plus their associated methods put together is essentially serves the same purpose as class, but in C struct only used to holds the state.
Easily, One of the best features of Go: capitalized fields, methods and functions are public. All the other fields are local to the package and not exported. With a single look you know if something is public or private. There’s no protected because there is no inheritance.
There is no concept of inheritance. Here is what Go FAQ says:
Object-oriented programming, at least in the best-known languages, involves too much discussion of the relationships between types, relationships that often could be derived automatically. Go takes a different approach.
Go interfaces are very different from JAVA or PHP, and one key concept is that interfaces are satisfied implicitly. Interfaces are typically very small, up to being just one method. You won’t see long lists of methods in idiomatic Go.
Interfaces provide polymorphism by accepting an interface, you declare to accept any kind of object satisfying that interface.
In Go not everything is an object (and technically nothing is an object, but some people call type values and variables “objects”), methods are functions associated to a type, but Go also allows functions to live outside an object, just like C functions.
So, although Go allows methods, it also allows functions, and first class functions (functions can be stored as struct fields, can be passed as arguments to other functions, can be returned from a function or methods return value).
Overall the Go implementation of object oriented programming is incredibly flexible and direct. Leaving behind classes and inheritance, you’ll see very little boilerplate, and instead of reasoning about the perfect hierarchical structure for classes, which becomes hard to change, you have the freedom to compose and decompose types as needed.
Here is my opinion as to why I would call Go as Object oriented language. Feel free to drop your comments or you can also drop me an email at firstname.lastname@example.org
Thanks for dropping by !!!