Object-Oriented Programming

This course views the topic of program design through the lens of object-oriented programming. Object-oriented programming refers to compartmentalizing related data together into objects; in python, this requires creating instances of classes and subclasses.

Basically, I see object-oriented programming as a tool for making programs easier to develop. Firstly, compartmentalizing, we are able to think about the design in an intuitive way. We have various objects, they each have properties, they interact with each other. That's how we think about the real world. That's how we *want* our programs to be able to work, because it makes them easier to understand, it makes them behave the way we'd expect.

Conversely, object-oriented programming is also useful in that it makes our code more organized without too much effort. Pieces of code that interact with each other will have a tendency to be close to each other, because they'll be in the same class. It gets easier to tell what a given line of code does when you can look to see what classes are named, and from there we see the classes' methods being called or their instances being modified. We can look at a variable and have a good idea, just from the class it belongs to, where and why it might be modified while running.

All in all, I look at object-oriented programming as a way of minimizing the effects of program complexity. When I am working with large programs with many interconnecting parts, losing clarity in terms of how my program actually works is a concern. I want to be able to compartmentalize, to put relate things together, to organize. In simple programs, I can see how object-oriented programming might not be useful: the act of creating the class structure might add more complexity than the class objects eliminate (in the same way, I would argue that docstrings are not useful on two-line functions). When the clarity is already there, when someone can see the program's purpose and inner workings at a glance, then defining new objects does not help the reader in their understanding, and may even then be counterproductive (although, as with the docstrings, we are encouraged to use them in the hope that we will form good habits). Beyond that, in most programs of complexity, I see object-oriented programming as a tool for trying to keep confusing things manageable.

On a related note, my personal cue for using classes is this: when I have series of nested functions, and the inner functions are using and modifying global variables, that's when I know I should be using class objects. I could get around this by carrying variables, one-by-one, through the function definitions, but using classes makes for much cleaner code, and much less frustration. Through compartmentalization of the variables, putting related ones together, classes make accessing variables much simpler.

Preamble

Before I get in too deep, I'd like to get a mission statement out of the way.

I hereby devote this blog to my experience through the CSC148 course here at UofT. I'm going to use this blog to note the things I learn, and, in at least some respect, to record some idea of my manner of thinking with approach to this course. I will not, however, use this as a mere platform to regurgitate lecture content; I'm sure there are better places for people who seek that kind of content. Rather, I will try to focus on my own encounters: things that surprised me, or that I had trouble with. In addition, I'll offer my own perspective on the course material, my thoughts on problem-solving within the course, some ideas on subtopics that have caught my interest, and perhaps some commentary on the structure of the course itself. Dear readers, whoever you are: thank you for being here, I hope I'll be worthwhile.

I'll try to make sure I post regularly. The course's weekly labs should ensure that I have at least a little bit to talk about. The first update should be up shortly.

--David