Summary of Object Oriented Programming concepts

I couldn't think of a better name. Anyways, here is a nifty little overview of some OOP concepts we've covered thus far in CSC148.


I) Objects:

Perhaps the most important concept of object oriented programming is the titular objects themselves. Most python textbooks or websites will define an object as being a representation of a value, with a memory address that points to that value somewhere in the magical world of computer memory. For instance, the number 4 is an object. The memory address to the value of 4 is the same regardless of how we are pointing to that object, and any variable that refers to the object 4 will be considered identical (since they all point to the same value in computer memory, regardless of how that 4 was obtained).

>>> s = 2+2
>>> t = 4
>>> s is t
True

Note that the value to certain objects is not always the same. The mutable types, such as list objects, are a prime example. Even if we assign 2 variables the same value - an empty list- they will not be considered identical:

>>> t = []
>>> s = []
>>> s is t
False

Although its not obvious at first, the reason this happens is because the empty list s refers to is actually a different empty list than the one t refers to. If something is added to one, it will not be added to the other. However, they are still considered equivalent, as:


>>> s == t
True

In order to better explain the philosophy behind objects, I must a few related concepts first.


II) Classes:

A class is usually defined as a blueprint for building an object. Now, remember how we defined objects as values with associated memory addresses? Well, lets expand on that a little.  Suppose we are using a programming language that has no classes. In this language, we could type in a sequence of alphabetical characters which just so happen to spell out the phrase "brown_nosing". Now what? Well, logically speaking, a human can do many things with it- like count every character in the sequence, or to create a copy of it in all caps. Or perhaps add the phrase "I_am_a_" to the front of it. We could simply create a new sequence of characters every single time- but that would be time consuming, wouldn't it? Plus, to make matters worse, we would have to completely create other, unrelated sequences of characters too, such as "you_are_an_amazing_person". Now, imagine if we could somehow take an already existing sequence of characters, and somehow be manipulated? Or better yet, what if every sequence of characters we create- regardless of which specific characters are used- have the potential to be manipulated in the same way? Well, that's what classes are for. With a class like- I dunno, strings- we can "string" objects- which are instances of the string class. All strings share the same sorts of basic properties, and can be manipulated in the same general way. For instance, whenever you put a "+" between two strings, they will be combined, or "concatenated", into a new one. This works with all instances of string objects, regardless of which specific characters appear in it, so now we can add the phrase "I_am_a" to the front of "Brown_noser" just as easily as we could to the phrase "fan_of_you".

In our hypothetical language without classes, there are no "defining features" to any given "thing" in a program. Every sequence of characters is considered a unique thing. However, we have an intuition in the world that certain things can be grouped together. For instance, when I visit my parents, I have this intuition that the little furry mammalian creature that jumps on me is, in some important sense, the same as the other little furry mammalian things I see in other peoples homes. I know that they can be grouped together in some meaningful sense, and that doing so can have great pragmatic value (such as making sure none of them consume chocolate). In my view, classes try to capture this intuition we have about the world. It allows us to group similar things together in a meaningful way, which can greatly improve the efficiency and organization of our programs.

And now, here's an uncreative transition to a few more OOP concepts.


III) Properties of Class members

Now, what do I mean when I say that all members of a class share properties? Well, try to thing, on an intuitive level, what kinds of properties things in the outside world share. Consider an elephant. An elephant has things it can DO- such as  blow water out of its nose/snout thing. It also has things that represent what it IS- for instance, it has four legs and a long, tube-like, nose things. Now, suppose we want to somehow create a bunch of virtual elephants in our computer (because hey, Watson wrote a cook book, so why not?). Now, if we make each elephant object an instance of some broad "elephant class", than this class could determine some of the attributes and abilities of each elephant instance. These are the roles of methods and instance variables, respectively. Methods can be thought of as "instance functions", since they are functions that exist inside of every object which is a member of the class the method was defined in. Instance variables operate in a similar way, except for variables which store values. Also of note is that these properties can be at either class level (in which every member of the class shares the exact same property initially), or at an instance level (in which the property is set when the instance is created, and usually varies between instances). Which types of properties you use, and on which level you use each of them, will depend of the type of problem you are trying to solve.


IV) Inheritance of properties

In much the same way that an object is an instance of a class- a class can also be an instance of another class. When this happens, some of the properties of the superordinate class can be shared by the subordinate "children" classes. This is inheritance.


V) Implications of the Instantiations of Classes:

Now, this is the last thing I want to cover. There are very technical terms I could also cover, such as the concept of property and the distinction between extending and overriding, but, in my opinion, they are really just variations of the same abstract concept of instantiation. When you instantiate, you create an object which is an instance of the class. This part should be clear by now. But think about the implications for a moment. This means that often, there is a one way causal relationship between a class and the instance of the class. For instance, if all instances of class A initially receive property B, than an object has property B doesn't necessitate that it is a member of class A.

The same thing applies to subclasses. In fact, you can completely override the properties of a subclass so that it functions completely differently than other subclasses of the original class (or the original class itself). So if every subclass of class A inherits property B, we can't even be sure that a given subclass of A will still have B. This is called "overriding" a class. Similarly, you can add new properties to it- which is called "extending" the class. So in this case, if a subclass of A has property C, we can't be sure that the original class A or any other subclasses will also have C. Again, the direction of causality is very limited. In the end, whichever one of these techniques you utilize will depend on the problem at hand. In the workforce (from what I've been told), it's considered bad form to completely chance you code if other programs are working with it. In these cases, you would want to utilize extension, since the prior code would continue to run as intended, while newer code could utilize the newly added functionality.

Anyways, I hope that this was a suitable summary of some object oriented programming concepts. I wanted to cover what, in my opinion, was most fundamental to understanding the OOP philosophy, without going over too much. Well, that and I've been typing this for an hour, so now I need to sleep.


EDIT this is one of the 3 blog posts that is intended to be graded.