Notes from the course Learn How to Code: Google’s Go Programming Language
Like all languages values are of certain types. Types can be int, string, boolean, etc. Within Go, you can also define your own types.
In the above example, eliot is set to a new type called “hacker.” As we know in Mr. Robot, Eliot is a hacker, so this type has the underlying type of boolean.
In the main function, eliot is set to true. Verifying this and its type is done with the Print statements, which output:
In a post from 2013, Bill Kennedy writes:
I consider Go to be a light object oriented programming language. Yes it does have encapsulation and type member functions but it lacks inheritance and therefore traditional polymorphism. For me, inheritance is useless unless you want to implement polymorphism. With the way interfaces are implemented in Go, there is no need for inheritance. Go took the best parts of OOP, left out the rest and gave us a better way to write polymorphic code. –From Goinggo.net
If you search long enough, you’ll soon discover that this topic is covered (and debated) quite a bit. Yes, Go is Object Oriented, but it lacks the traditional elements we associate with Object Oriented Languages (like classes, inheritance, etc.)
In Todd McLeod’s course on Go [link] he states that Go is OOP with these elements you would find in other OOP languages:
- Reusability through inheritance or embedded types
- Polymorphism through interfaces
- Overriding through promotion
The above seems a tad contrary to some of the other links and discussion that I’ve come across. However, Todd makes a good argument for these points.
Regarding Encapsulation, Todd states that by creating our own types and that type has fields that hold state. Those types can be associated to behaviors (like methods.)
For Inheritance, Todd adequately shows in the course that a type can be injected anonymously into code. When done, all the fields that were part of the struct are carried (promoted) with the injection.
As for Polymorphism, Todd McLeod explains that interfaces fit the bill.
Finally, in regards to Overriding methods/functions, Todd McLeod shows that through “promotion” a function can be overridden. This is a complex subject for me. However, in watching and rewatching the lecture several times I have an idea of what he’s getting at. Below is a code example I wrote, that follows his own:
In the above code the output will be:
FORD MOTORS Mustang 1973 Ford
mustang.Make prints out “FORD MOTORS” and mustang.Car.Make will return the value “Ford.” What occurred here is that the Car struct was promoted into the Demolition struct and and when we set a value to Demotion, we created a set of values for the mustang car. However, another definition of “Make:” was created which shows overriding the initial value.
The reason why I started with the concept of Types is that the instructor (Todd McLeod) brought up the idea first before going into Structs. Here’s why – When making Structs in Go, you define a type of struct.
A struct is a data set that resembles (at a glance) something akin to a class in other languages. Example:
The value mustang is of type car. It is reminiscent of a class being instantiated as objects. I’m not sure if that’s what’s actually happening… and my understanding of the deep waters of OOP is quite limited.