Skip to main content

A Hundred Days of Code, Day 003 - Methods

Learnt about methods today.
Notes follow …

My understanding about methods? They are functions in classes that help me manipulate the data the objects contain when they are created.

I have been using something them subconsciously all along.
The __init__ method, that is called/run automatically every time an object is created.

Aha
A nice way to unpack the .notation i use

Let’s say I have a class SquareNumbers that has a function (method) ­— x2 — that will, you know, square a number.
And then I create an object f with a number and call the square method on it.

f = SquareNumbers(10)
f.x2()


What I am actually doing, when I call f.x2() can also be written as SquareNumbers.x2(f).
I am sending a message x2 to the f object, and it will respond with however/whatever it is programmed to.


When I define object variables in a class, I should refer to them with a self.variable when I define methods.
I figure because each object can have it’s own set of values for those variables and I want Python to find them properly.

Also learnt this is not the case in most other languages.
With some languages, you set and get values of variables of the object, using even more explicit methods, call getters (accessors) and setters (mutators).
These are just fancy names for explicit methods to assign and then read data from the variables of a class.
In our example above, I would probably have a set_x function defined to set the value of x like f.set_x(20) (along with a corresponding get_x to read it)

This could also be because other programs have different categories of data (private, public) in classes, while Python does not.
Just differences in language design philosophies, I guess.


I can create an class, that can use objects created by other other classes.
For example, I can create a book class and then have several book objects.
And then create a new bookshelf class, whose objects can take all my books and put them in a list/library of sorts
This kind of relationship is called a has-a relationship in programming parlance.
(like my bookshelf has-a book on it)
It’s also called composition. I am composing a new class from other classes.
I can do what I want with the list in the bookshelf.
I could take their prices (if i added them) and then sum them up.
I could take the titles and list them alphabetically, or by author.

Aha

So what is becoming clearer to me is that classes can take user needs, and express them naturally, while leaving the creation of these calculations and listings and sortings with the programming language primitives behind the scenes.
For my book shelf i could just go shelf.sort.title.alphabetical()
Or if I have a new need tomorrow, hmm, like finding the total prices of all my books, I could just add a sum method to my bookshelf and I could go shelf.sum().

It basically makes my code, more human. More easy to understand. More natural.

Another thing that just occured is that I could swap out the primitives beneath the classes. If I find a faster, better way to sum up prices, I could just use that. While the way I would sum the books would still remain shelf.sum()


Doing the exercises, I realise that I need to learn a lot more Python vocabulary.
I somehow managed to gather a number of variables into a list.
But when I attempted to do it again, it threw an error.
And that’s when I learnt I could extend a list.
Lots more practice needed!

The self thing bit me hard!
I spent at least a 45 minutes trying to find out why my method could not find a variable, despite me defining it correctly. I should’ve obviously referred to it with self.variable!

Time to call it a day.

Read all about my OOP journey here