Unit 9 - Object Oriented Programming 1 (OOP)

This week, we begin object-oriented programming. Object-oriented programming is sometimes considered difficult, but the concept is simple:

Instead of writing one big monolithic program with a bunch of functions, you write a bunch of simple, small, self-contained programs, each with their own functions. Then you make the small, self-contained programs communicate with each other by invoking each other’s functions, which collectively does the same thing that one big monolithic program would do.

Done properly, a bunch of little programs should be easier to write, easier to debug, and easier to maintain than one big program. Also, you might be able to re-use some of the little programs in other applications or other parts of the same application.

At least, that’s the idea. Whether object-oriented programming actually is easier than writing programs only modularised with functions is a matter of some debate (and largely beyond the scope of this module), but object-oriented programming is pervasive in the industry and will likely remain so for a long time, so it makes sense to learn it.

To summarise what will be covered:

• A class defines instances, also known as objects, of that class. The relationship between a class and its instances is 0-to-many; you have a class and zero or more instances of it. This relationship can be understood in different ways:

  • A class represents a category; an instance is in item in that category. For example, my little buddies Calvin and Indi are instances of the class Cat.

  • A class is like the source code for a small, self-contained program. An instance of a class is that small program loaded into memory and ready to run.

  • A class can represent a data type. Just as built-in types like int, float, and str are data types (and 3, 3.4, “fish” notionally instances thereof), you can create your own data types using classes and create instances of them. For example, you might create a Book class with instances “20,000 Leagues Under the Sea” and “The Hobbit”.

  • A class is like a blueprint; instances are things made from the blueprint.

• You can make an instance do things by running, also known as invoking, its methods. A method is simply a function associated with a particular class, and thus all its instances. Collectively, methods represent the possible behaviour of a class, and thus all its instances.
• An instance usually contains data. This is stored in instance variables (sometimes called member variables) or fields. The data in instance variables is often described as representing the state of an instance. If the data in an instance has changed, we say the instance’s state has changed. In Python, the preferred mechanism for reading or changing instance data is via attributes or properties. We can also use methods to read or change instance variables. In languages like Java, the only way to read or change instance variables is via methods. In languages like C#, using properties is preferred, but methods can also be used to read or update instance variables.
• We say that an instance “can take care of itself”. In other words, you can ask an instance to do things (by invoking its methods), but you don’t have to know or care how the instance does it. You communicate with the instance – i.e., tell it to do things, or retrieve or change its data – through public methods and (in Python and some but not all other object-oriented languages) properties. The internal implementation details of the instance are kept hidden (i.e. private). This hiding of the internal implementation and data is often known as encapsulation.

If you’ve not done object-oriented programming before, this may seem complicated and confusing, but it will become clearer over the next few weeks – and beyond if you take Programming II.