Week 7: Down and Dirty with OOP

To discuss in more detail the conceptual ideas of Object Oriented Programming, refer to last week's post; this week we'll be looking at how Python handles OOP. Let's first look at the structure of a class and what it entails:

The class is defined on line one and given the name 'Circle'. The __init__ method runs the moment the class is instantiated (we make an object of the class). We can see that the instance variable of this class is 'radius'. Since it is an argument of the '__init__' method, we must pass in an argument when creating an object of class Circle. However, if the parameter is assigned a value in the  method definition, it will be defaulted to that value if it hasn't been mentioned in the object initialization. Here's some examples:

Line 11 will run regularly and create an object of class Circle with a radius 5. Line 12 will give us an error because the __init__ method did not set a default value for the radius, and you are not allowed to create an object of the class Circle without giving it a value for the radius.

Now, on to line 6. Any method can be run by accessing the objectname.methodname(). Every single method must be defined with at least the parameter (self) - think of it as the class making sure that it can access it's instance variables. Here's some sample code to demonstrate OOP a little more complexly:

I've added some docstrings and an additional method to spice things up a bit. Here's the main:

You can see I've made 2 different objects of Circle with 2 different radii. obj1.radius gives a different value than obj2.radius because they are different Circle's with different properties. This is what the shell would show following having run the program:

Methods initialized with double underscores on either side are special, because they are called without being explicitly called - i.e. they are called when you perform other manipulations on objects. An important thing to realize about objects are that they are packages of data. If you say you want to to "ride the Six Flags Theme Park", you'll likely be looked at in an odd manner because this makes no sense - rather, you want to go to the Six Flags Theme Park and ride the individual rides. In a similar way, you can't add two objects because they are not single integers, they're much more complex than that. For example, if you try to do obj1 == obj2 without defining a '__eq__' method in the class, the computer will try and compare the memory addresses of the objects to see if they are the same object. Remember: if I create two objects with the same attributes, they are still separate packages of data that exist at two different addresses.
Here are some important methods you should define in a good class implemented for Circle:

And demonstrated in the shell:

Now that you've seen and understand some uses of OOP, I'd like to a few words on the magic of this concept:
Object oriented programming allows one to set up organized and efficient code, and helps you avoid having an overload of variables and oddly represented data. Yes, classes are like recipes, thank you Grade 11 ICS teacher (refer to Week 6).  A class sets up the structure and blueprint of something that has the potential to exist in memory - creating an object takes that structure, copies it, and allows you to create a tangible set of data that is organized and makes sense. OOP makes way for Abstract Data Types such as trees and linked lists, which are all based on the concepts presented in this post.

Week 6: OOP-De-Loop

Object-Oriented Programming! What an important programming concept. Once I learned how to effectively implement OOP, I never wanted to go back to purely functional programming. However when I first learned about what an 'object' was, I was far from convinced.

I still remember it like it was yesterday - it was the night before my Grade 11 Introduction to Computer Science exam and I was on the phone with my friend who was going through an impressive list of metaphors to try and help me wrap my head around the idea of 'objects'. That phone call lasted about an hour and a half before I hung up, extremely frustrated. Why does everyone keep talking about recipes? And what does the human race have to do with classes? Long story short, I did the exam pretending to understand what an object was (and I did surprisingly well, considering). Two years later, I sit here in the very same spot I was sitting when I was on the phone trying to wrap my head around objects, with a complete understanding of classes and object-oriented programming. It took a summer of re-doing the Grade 11 ICS curriculum and three half-year courses, but finally here I am. And now I'm obsessed.

To explain the basics in a way that I wish I was taught, think of an object as a circle. And that circle has arms (you can have as many arms as you like - for this example, let's say there are 3 arms). Each of these arms represent a different feature about the circle; say, the circle's favorite movie or it's favorite color or it's last name - just features of the circle. Now, different circles may have different preferences of colors and movies but at the end of the day they are all circles with preferences.

Following this example, the class would be a Generic Circle with three arms. Since each of the above circles all came from the single Generic Circle (class), they would be objects of the class (each object is an instance of the class it belongs to). And finally, each of the arms are called instance variables, basically just attributes or 'preferences' of the objects. Often times you can make classes do things or give you outputs by creating functions within the class called methods, but more on that later. More complex ideas such as inheritance and super-classes will be elaborated on next week. I hope this helped you understand the conceptual idea of objects in relation to classes - we'll get more down and dirty with actual code soon!

Week 5: Tracing In Circles

Come one, come all! Gather 'round, don't be shy! Bring your mother, brother, sister, father, cousin and neighbour you have a questionable relationship with! Witness the magical capabilities of our latest act - Recursion! 
We've been waiting to be offered the deathless death of recursion (yes I'm listening to Hozier as I write this) since last semester's 148 students wrote their second midterm and came out bathing in their tears. Finally, it's here - well, kind of. We've been tracing recursive calls this week, and it really hasn't been all that bad. As far as I can tell, it's the same process as Alice traveling through Wonderland - you keep going deeper and deeper until you reach a turning point where you can't go any deeper, at which point you have to leave with everything you picked up along the way.

Okay, I'll try going the rest of this post without going on too many tangents.

Danny's introduction to tracing recursion was very useful, and it really helped me understand how and why each step was happening. It was very interesting to see how such short pieces of code could produce such long traces, and be so powerful. Not to mention the representation of recursion using the Turtle drawing module was pretty freaking cool. I'm interested to see how recursion is used in application in future classes and labs, and I can't wait to begin writing some recursive code on my own as well.

Week 4: Who's Your Daddy?

Alternate Title: Look How Far We've Come (Part 1)

This has actually been my favorite of all my courses this semester, so far (which I hope is an acceptable statement as I intend to pursue a Computer Science Specialist degree). We've been introduced to the idea of inheritance in class this week, and the practicality of using parent classes has definitely dawned on me. The applications are literally endless and I really appreciate how this concept stresses efficiency (which wasn't always a focus in CSC108). Inheritance allows for bigger ideas to be executed in much cleaner ways, as well as symmetry and consistency which I think is important to reinforce the idea of writing clear code. We discussed how Python calls methods in regards to inheritance, and how it interacts with over-ridden and inherited methods. All-in-all I'm really enjoying the topics discussed thus far, and my appreciation for code-equitte (code-etiquette - so clever, I know!) is definitely growing.