Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.
Object Oriented Programming (OOP) is all too often viewed by those unfamiliar to it as a science to be mastered. OOP however, is an art...a methodology, a simple (but powerful) way of defining what a program is. After going through many tutorials on the subject some of us still scratched our heads and lamented, "Interesting philosophy, but I still don't know how to do OOP." We wanted to master a science and we couldn't find the telltale step-by-step instructions we were looking for. So, I've written this article to save you that frustration.
Placing objects inside a program does not, by itself, make it Object Oriented. For that to happen we need to consider how the parts of a program relate to each other. Instead of thinking of a program as a bunch of instructions just thrown together to do something, OOP looks at that same program as related functions and variables that are then grouped together in common sense ways. OOP then draws borders around those different groups. Don't make this more complicated than that. That's it. Related subroutines and variables are gathered together in groups (again, in common-sense ways). These sets of subroutines and variables in a group make up a Class(which is just a blueprint for an object). For example, a dog class may have a "doTrick" subroutine and a "breed" variable, but no "sweater-size," that's just not common (at least it isn't yet..give 'em their dignity). An object is created using that class blueprint (just as 'integer' is a blueprint when you declare "i" as 'integer'). In OOP, a variable like "i" can be defined as 'dog.' The difference here is that you, the programmer, write the code that defines what 'dog' is. The variable gets declared, filled with data (optionally) and then can be passed around like one big variable. Now let's think of some rules governing what parts of that object can be exposed to other objects and what parts should not, aka public/private “Encapsulation.” Well, 'color' is seen by people, they get your dog's color but can't set color. Yes, I know, purple poodles (what are their owners thinking?!). And there you have yourself the essence of Object Oriented Programming.
Now what if you have a 'dog' class and you decide you need a 'fancy dog' class (one with sweater-size and, okay, I give...color)? Answer: Yes, you do write a new class, but no, you do not copy and paste the code from 'dog.' You reuse the code in a different way. In OOP you just create a new 'fancy dog' class, and in it (using key words) you tell it to inherit from 'dog', then just add sweater-size and color as variables (making color settable) ….and now you're dong serious OOP!
“Loose Coupling,” "Composition," "Aggregation," and other OOP terms (like UML, the diagramming practice broadly used in OOP) are concepts you should learn. That being said, those concepts really aren't too hard to tackle once you’ve master the ideas discussed here.
**If you found this article helpful, please giving it a "Thumbs-Up" (below and to the left).