Classes in GoLang?

GoLang is a programming language, it is kind of different and weird because it is an Object Oriented Programming (OOP) Language but does ̶n̶o̶t̶ have the concept of classes in it.

Now you must be confused, right? But once you get the hang of it, GoLang is really a well-optimized not only for programming but also a well-optimized Object Oriented Programming Language.

As known to any software-techy person, Object Oriented Programming is an approach that comes into the picture when the software/program is expected to work according to real-life scenarios/problems. So, this “Object” is a way of representing any real-life entity in terms of programming as it can have properties similar to any real-life object (for instance, an object of a car can have properties like RPM, No. of gears, No. of seats, etc.). Further, these properties are defined within a blueprint called “Class,” according to which the object is allocated with memory when the software/program is in the execution stage.

Therefore, to create a representation of a real-world-like programmable entity object is absolutely required, and to create objects in a software/program, classes serve as a blueprint for the programming languages to assign memory to the objects during the program’s execution. In such a way, OOPs concepts are based on classes & objects.

And now that we know that classes and objects are the very basic entities for OOPs — Go Programming Language does ‘n̶o̶t̶’ implement the concepts of classes.

This is what a programmer starting off with Go Programming Language tends to believe. So now what? Is Go even an Object Oriented Programming Language? Well, here’s the answer:

Usually, in the majority of the Object Oriented Programming Languages, to define a class, there is a keyword called “class.” And anyone who’s aware of the classes is also usually aware of structs as well. Structs and classes are both used to pack multiple variables together as a unit. But when it comes to GoLang, it does not use the keyword “class” to declare classes. It has the “struct” keyword to declare not only, obviously, a structure but also to declare a class. And the analogy for that is, “If structs are already there to pack the variables together within a unit, then having classes is redundant.” Yeah! Literally “redundant.”

So, looking past the furiousness about the whole “redundant” thingy, let’s jump onto the explanation of what is stated above.

I know that structures are not meant to have functions/methods within them, and classes can have functions/methods within them which can change the properties/variables within the classes as per the requirements, which in turn allow the objects to act as real-life entities(i.e., to change the values of the variables within the object as per real-life conditions).

Here in GoLang as well, structures cannot have functions within them. Functions are always declared outside. But in GoLang, just to associate the packed variables with the set of functions that can change those variables as per the conditions, the idea of bringing a whole another concept of packing the variables together (namely classes) is what is referred to be “redundant.” GoLang says that all that is required are functions that can change the variables within the structures and that those functions can only be accessed via their objects (just like the functions within the class can only be accessed using its object). So, the functions can stay outside as they always are, and they can still somehow be associated with the structures, such that the values within those structures are accessible within the scope of their corresponding associated functions. And hence, classes are not required in GO.

Get McKinley Rice Blogs’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Now to understand this better, first, let’s look into how a normal C++ class looks:

In the above car.cpp file, if we break down the car class, we can say that:

1. Its object would comprise the RPM, No. of gears, and No. of seats as its member variables(data).
2. Its Member Functions can only be accessed by using the object of the car class as done from lines 37 to 43.

Now, had the car been a struct instead of a class, then it wouldn’t have member functions, but still, it would satisfy the first point stated above. And in GO as well, the structures work in a similar manner. So now the whole thing is about the second point, how to associate the member functions with the structs in GO.

This is where Go brings in the concept of “Receivers.” This is a concept that exactly fulfills the second point stated above. If a function has a Receiver of a structure associated with it, then it can only be called by the object of that structure. And this is how it GOes:

The syntax :- func (ReceiverObj ReceiverEntity) FunctionName(Params) ReturnType {// funcBody}

• If a receiver-free function is required, then just remove the receiver parenthesis before the FunctionName.
• If the return type is void, then right after params parenthesis, just begin the function body with the opening curly bracket.

Now, this is how the above C++ Car class equivalent code in GoLang:

As shown in the car.go above; this is pretty much how GO implements the concepts of Classes without even using classes and using structures instead.

Written by: Ashutosh Gusain, Associate GoLang Developer.