This post is part of a series aimed at bringing people up to speed in what’s going on today in application development. 

What I want to do here is talk about the basic principles of OOP that you should be aware of.  I’m not trying to teach you everything you need to know, but I want to give you my interpretation, a basic understanding, and some pointers to more information that you should use to further your knowledge.  This was supposed to be a single post but it grew beyond 10 pages and so I figured I’d break it up into 4.

OOP is one of those things that everyone has a different way of explaining.  We’ve all seen analogies about Cars and Corvettes, Persons and Employees, and whatever else.  What I’m going to do is explain from my practical usage.  (Please correct if wrong!)

There is a lot to object oriented programming, and OO languages.  Some I will talk about, some I won’t.  Some is not strictly related to OO but is often part and parcel of doing OO programming.  However, regardless of what you think falls in the realm of OO and what doesn’t, it all starts with the 4 pillars:  Abstraction, Inheritance, Polymorphism, and Encapsulation.

It’s important to know that, depending on who you talk to, these (and many other) principles in software development will have different definitions.  You also may find that the lines get blurred between concepts, particularly when you talk about the realities of practicing OOP versus just defining it on paper.  That’s ok!  Our field is very dynamic, and what I want to do is fill you in on the basics so that you can effectively communicate with other developers and further your own understanding.

Let’s start with Encapsulation.  From Wikipedia:

a type of privacy applied to the data and some of the methods (that is, functions or subroutines) in a class, encapsulation ensures that an object can be changed only through established channels (namely, the class's public methods). Encapsulation means wrapping up of data and associated functions into a single unit(called class).Each object exposes an interface — those public methods, which specify how other objects may read or modify it. An interface can prevent, for example, any caller from adding a list of children to a Dog when the Dog is less than one year old.

Ok, so what’s all that then?  Encapsulation, in a nutshell, is the practice of hiding the implementation of an object and controlling interaction with that object via an exposed API.  For instance, remember the code to send email in classic ASP? (been a few years since I wrote any classic ASP, so may be off a little, but if memory serves, it might go a little something like this)

Dim mail
Set mail = Server.CreateObject(“CDONTS.NewMail”)
mail.to = “scott@scott.info”
mail.from = “me@you.com”
mail.subject = “Drastically Increase Pen1s Size”
mail.body = “lolz I said pen1s”
mail.Send

Okay, so that’s encapsulation at work  We are looking at encapsulation in action throughout the code.  Mail.to, mail.from, etc, are all Acessors/Mutators of the mail object.  An accessor is a way to ask an object for information it contains, and a mutator is a way to ask the object to change information it contains.  Properties such as the ones in the code above are both accessors and mutators depending on how you use them.  You are setting public properties on the object.  Internally you can figure mail is using these properties to put together your email, but you don’t have to care about that, because the API provides public properties for you to set and then handles the implementation inside.  This is what is known as a “black box”.  You don’t see what’s happening inside, and as long as you get the expected results, you don’t care.  Encapsulation.  You’ll see a little later how this relates to Abstraction and wonder if the lines aren’t blurred a little…and they are.  But for now, just know that Encapsulation is the act of restricting access to the internal data of an object by exposing public methods and properties that control interaction with the object.