This tutorial gives a brief and, extensive explanation of the simplest object oriented programming techniques.
Ah, a concept that confuses many. A concept that dominates the higher-level languages. Perhaps the most relied on paradigm in programming. It is, the object-oriented paradigm.
I think it is important to define ‘paradigm’ first. Generally, the term paradigm refers to a thought pattern in any scientific discipline or epistemology (thanks Wikipedia :-)). In the context of computers, however, it has a different definition, but I like to think of aforementioned definition and name a paradigm: ‘the computer’s thought patterns’.
A programming paradigm is a “fundamental style of programming regarding how solutions to problems are to be formulated in a programming language”. Examples of these are, imperative (often referred to as procedural), object-oriented and event-driven, there are, many, more. It is important to note that a programming language can support more than one paradigm simultaneously programming languages such as C++ and more recently, PHP are multi-paradigm. I plan to talk about this paradigm in the context of PHP as that’s what’s most applicable to this blog, really…
Let’s start with a few keywords: object, class, inheritance, polymorphism, methods (functions :P), fields (states), abstraction, encapsulation.. ah, now, what the hell are they? Let’s start by going, what seems to be, completely off track.
If you look around the room that you are sat in you will see many objects, let’s chose the television as an example.
Now, every television has properties, that are.. the same.. in every television. For example, they all show videos, they all receive the video data from some source and let’s assume that they all make sounds. This is really, the blueprint for a television; the typical attributes of the television. Now, let’s compare this to a class, let’s break up the attributes of a television into two categories, methods (behaviour), and fields (state).
To turn the television on, would be a method: a method is a behaviour, but like I to think of it as an action that the class performs to process data, to turn the television on would be a method, because it is an action therefore some processing must occur. It’s a lot easier to apply the term ‘behaviour’ later, if you already know about objects.
If the television is turned on or not, would be a field: a field is a state, however, much like methods, I have my own way of referring to them, try to think of fields as the details of the class, like, a television may have a field named ‘make’ and the value would be defined later. The field for whether the television is turned on or not would perhaps be called ‘onoff’ and it’s value would be defined when the television is turned on, or off. (For those of you who know about data types, the field on off would be of the datatype boolean.)
So, a few more examples:
To change the channel, would be a method, a function, an action. The current channel number would be a field, a state of existence. Think of a fish. To swim, is a method, or an action. The fish’s name is a field. The fireplace? To turn it on or well, turn the gas or electric on, is a function, an action.. and it’s current condition, or state, would be, on or off. (If you’re a bit of an English geek you could look at the methods as verbs and the states as nouns). I hope you get the idea now, because that, and the next but are the hardest things to grasp.
Ok, now let’s continue with the example of a television. We now have our television class that dictates what state it is in and what it can do. However, a class it is just a blueprint, a non-existent blueprint for something that could exist. It doesn’t actually exist. So let’s create an object, an existence based upon the blueprint that is, the class. We’ll make a television, our television is a typical television object derived from the television class (blueprint), we could have many televisions from our one blueprint, infinite amounts in fact, all in different states (on or off, channel 45 or channel 32) and all processing different actions (turning it on or off, changing channel)… now to make object oriented even better, more defined, we make it even more versatile with something called ‘inheritance’.
| Note: As soon as a class is created it looks for a method that is known as the constructor. The constructor sets up all necessary fields that would normally be expected to exist on start up, it gives the class, characteristics.. let me elaborate. If you bought a television you’d expect it to be more than the plain blueprint suggests, as the blueprint works for all televisions, you’d expect it to have a brand name, a colour, a size.. and you’d also expect it to be IN a state. Remember, a class only defines the possible states. When you define a television, you’d want it to apply a onoff value, because a television MUST be on or off, physically, however, the blueprint only has a field that says whether it’s on or off. So once I create my television object, I’d expect the constructor to set it to the off position. There are also, de-constructors, but they’re not important at the minute. This topic definitely deserves more time, however, I’ll revisit it later. |
Now, let’s avoid the name for now, because, although it makes perfect sense eventually, it doesn’t at the beginning. Let’s slip back into context but this time (not that it doesn’t apply to the television, because it does, but I want a change) let’s use a fireplace.
Ok, so we have our fireplace class (states: on/off, temperature methods: switchOn, switchOff, turnTemperatureUp, turnTemperatureDown). We initiate a fireplace object, an entity derived from the blueprint that is the fireplace class. So, I have my brand new fireplace, but is it electric or gas? This option COULD be a state.. but it isn’t really a state of being is it? States change, that’s what’s unique about them. An electric fireplace cannot suddenly become a gas fireplace. To fix this problem we create a new class based upon the original fireplace class, the electric fireplace class (technically, a fireplace is the whole surroundings of the fire and the fire itself, but I’m going to use the term fireplace anyway). The electric fireplace class does everything the fireplace class does, but more, the turnTemperatureUp and turnTemperatureDown methods are the same, but the switchOn, switchOff functions will work differently (ok, you can argue that so will the temperatureUp, but let’s not get fussy). Therefore, the electric fireplace class INHERITS the fireplace class. It’s the original code, plus a little bit more.. more examples of this are.. as we said originally, the television. A flatscreen television class would inherit the television class (parallel to the… non-flatscreen television class) and the LCD television class would inherit the flatscreen television class.
Now, here’s a term you have to remember, the original class is called the superclass and anything derived from that is called a subclass, respectively. They are also referred to the parent class and the child class. I robbed this image from Java’s tutorial on object oriented programming (which may I add, is excellent). Here’s a little key, the little shapes inside the circles are the fields, the states, and the blocks around them are the methods, the functions or the actions. (I like to use three key terms to refer to them so that you remember exactly what they do).
Bike Concept
So far we’ve covered, objects, classes, methods, fields, constructors and inheritance. That’s quite a lot and definitely the basis of object oriented programming, you COULD leave now content that you’ve actually gotten something from this little article however there is still so much to come that would actually make you know almost everything there is to know in object oriented programming, we’ve barely touched the water. What’s next? Interfaces.
