|A Programmer's Guide To Go Part 2 - Objects And Interfaces|
|Written by Mike James|
|Thursday, 05 December 2013|
Page 1 of 2
In the second part of our mini-series on Google's alternative to C, it is time to come face to face with Go's most interesting features - objects and interfaces
A Programmer's Guide To Go
Part 2 Objects And Interfaces
Go takes a very different approach to objects than the class based object-oriented languages that most programmers are familiar with. You don't define a class and then use it to instantiate an object and there is no type hierarchy. There also is no inheritance, no function overloading and...
If this all sound as if Go is going to turn out to be a primitive low level language think again. Its approach is best described as low level yes but it also quite sophisticated.
So how do you create objects in Go?
The simple answer is you don't exactly create objects. You simply associate functions with types and you can use these functions as if they were methods of the objects or values that you create using the types.
A receiver acts like an extra parameter of a specified type passed to the function. If you know how objects work in other languages then you might recognize it as being very similar to the "this" parameter passed into object methods.
this binds the function Sum to the receiver type point. You can see that it looks like an additional parameter for the function and indeed this is what it is. The function you have created corresponds to a function type with a signature which has an additional parameter of the receiver type as its first parameter. This is also how receivers are implemented - it is very simple and low level. Notice also that unlike the use of a default receiver e.g. "this" you can give your receiver a sensible name.
Now when you create a point value you can also call the Sum method as if it was a method belonging to a point object. For example:
When you use the Sum method the value that it is being called from is passed as the receiver parameter. This is how one function definition can be shared between a lot of different values of the same type.
Notice that while in this example the method was attached to a struct you can attach methods to any type - except for the built in types. If you want to attach a method to a built in type you have to first create a new type with the same underlying type.
For example if you want to create an integer "object" with a square method you would use something like:
After this you can do things like:
There is just one complication but it isn't a difficult one. Go passes all parameters by value and this includes the receiver. This is fine as long as you only want to make use of the values that the receiver provides. If you want to change the receiver in any way you need to pass a pointer.
For example, if we change myint's square method to read:
Then it returns the same result but it doesn't change the value stored in i. To do this you have to pass the receiver as a pointer to the type:
Now when you do:
the result 9 is displayed but also j is changed to 9. Notice that you don't have to change the way you use a method to take advantage of passing a pointer Go takes care of it for you. However you do have to write your method function remembering to dereference the pointer.
It is true that the statement:
looks horrible, but this is about as bad an example as I can find. In practice things look better than this and the type checking helps you to not forget a dereference operator when you need one..
That's about all there is to Go objects. As stated in the introduction there is no inheritance and methods are not overloaded.
Wot No Inheritance?!
So how do you build an object hierarchy?
The simple answer is that you don't. Go encourages you to use composition which is, these days, generally thought to be more robust than inheritance.
Although some of the examples given earlier make use of more general types structs are the thing you tend to use to create objects. These provide data fields and by using the receiver mechanism methods. However as the field of a struct can be any type you can also have fields that are structs.
For example suppose we want to build a graphics library. The first thing we need is a point object:
Next we might need a circle object:
Notice that we have used the point object within the circle object - a circle contains a point object.
We can now create a circle in the usual way an we can use a composite literal to initialize it:
Now we can call the area method:
If you want to access the center co-ordinates you use a fully qualified name e.g:
So far so good - now let's introduce an ellipse which for the sake of the example we want to treat as a special type of circle, one with both a horizontal and a vertical radius:
Now we can create an ellipse using the same sort of composite literal:
Notice that we are now considering an ellipse as having or containing a circle which is not good design, but the point is that we can access the center of the ellipse using:
Notice that the qualified name is getting longer. This is the problem with aggregation. Each time you add an object which is made up of objects, which are made up of objects and so on, the name gets more complicated.
Go has a solution for this - don't give the new fields names.
|Last Updated ( Thursday, 09 January 2014 )|