OK, over the next few weeks we’re going to step back a bit from code and command, and instead take a straightforward look at object oriented programming, or OOP*.
Because it’s often something that crops up in interviews, and the main concepts are things that all programmers should be able to rattle off and feel comfortable talking about. If you come from a low-level, or even machine-level programming background, it’s still A Good Thing to know what this object oriented lark is all about.
OOP deals with objects
Unfortunately there is no standard definition of “object oriented programming” that everyone agrees on, aside from the fact that it uses objects, which is possibly one of the reasons why so many people use it day in and day out, but have trouble defining or explaining what they are actually doing.
OOP requires a particular way of thinking. Instead of planning out a sequence of instructions in your program, you need to think about what you might want it to do, break it up into useful objects, and then allow those objects to interact with each other. There is no set order or route through the code (although all paths should be testable, but that’s a different subject entirely!).
An analogy I often use is to imagine a room full of people talking to each other. Each person is an object, and each object reacts to what other objects around them are saying.
How is OOP implemented?
An object is a concept that is supported by an OOP language, such as Java or C++. Each language varies slightly in it’s approach, but the basic idea is that the language provides you with a way to define an object that you want to use, and then you can generate as many, or few, of those objects as you need.
In C++, you create (or instantiate) objects by declaring a class. A class acts as a template for your object creation. A class contains methods that dictate how the object can be used and how it will respond to stimuli.
The main principles of OOP
This is a subject open to debate, but I think there are 3 core principles of OOP, which memorably spell out the word PIE:
The hardest one to define. Polymorphism describes the ability of different objects to be accessed by a common interface. If that makes no sense, don’t worry, I’ll be covering this next week, and later providing a simple example, so when someone asks you in an interview, “Can you explain polymorphism to me?” you will never be at a loss for words again.
Inheritance describes the ability of objects to derive behaviour patterns from other objects. This is an amazing concept which opens up the ground for easily creating interfaces/APIs, and reducing the duplication of code in your program. I’ll take a closer look at this shortly.
Encapsulation describes the ability of objects to maintain their internal workings independently from the program they are used in. This basically means that you define object-related behaviour inside your object, and it therefore becomes self-reliant – you don’t need to have supporting code in place for your object to work correctly. Again, I will cover this in more detail very soon.
So there you have it. The three cornerstones of OOP, and a nice handy definition of each. Next stop: a more detailed look at polymorphism, coming next week!
*Random book recommendation
Whenever I hear the abbreviation OOP, I always think of Douglas Coupland’s novel, Microserfs. It’s getting on a bit now, but is still a fab book about disillusioned Microsoft employees leaving to create a startup. Give it a go: non-affiliated, just-for-the-love-of-it link to it on Amazon here.