OOP Concepts Applied In CFML: Abstraction

One of the most fundamental concepts you will need to grasp is Abstraction. Let's take a look at the Wikipedia definition and we can break it down from there.

In computer science, abstraction is a mechanism and practice to reduce and factor out details so that one can focus on a few concepts at a time. The following English definition of abstraction helps to understand how this term applies to Computer Science, IT and Objects - i.e. abstraction is: A concept or idea not associated with any specific instance

Like everything else in life people really like to complicate things to stand above the rest. When developers speak of OO you will often hear Encapsulation and Abstraction. At first it may sound complicated but if you look at the definition, it really is not.

Abstraction in the CFML land is something we all need to practice. I image anyone out there who doesn't know anything about OO has written what we now refer to as the Uber CFC. While this is not a concept you want to follow its much better than the alternative, which is cramming presentation and business logic into a CFML template.

We can use this as a great starting point for abstraction. Lets say we are writing a simple contact manager application for our human resources department. In our old application we might of had one very large Uber Component called Employee. This is a great starting point but we can easily improve the architecture of the application by applying the very simple Abstraction concept. Here is an example of what our Employee Component might of looked like before we refactor.

Properties
id
fname
lname
email
salary

Methods
init
get/set id
get/set fname
get/set lname
get/set email
get/set salary

This is not as Uber as you thought it would be but just bear with me for a sec. In a real world this component would be huge but I simplified it for this example. So the first problem we have is that we have classified every employee into one group. Taking from my own position you can easily break everyone down into 2 distinct categories, part time and salary. A part time employee would never have a salary property so why would set one. From this we could create an interface (I know I know, just run with it).

Update: I ran through this example so fast today I didn't event check my code. This example should be using Inhertiance (I am learning).

This may not be the greatest example but it show the exact reason to use Abstraction. Not all Employees are the same so you don't want to classify them as the same. Abstraction here breaks our employees into 2 distinct Objects. While we will want to treat them as employees some time there are time when will need to treat them as a part time or full time employee specifically. Without this level of Abstraction your component will start to get larger because now you need to know if the employee is full time or part time employee.

To take it one step further different departments may have different properties or behaviors that other departments do not. You could then abstract your employee component into different departments hr/engineering/payroll etc and then classify your employees into part time / full time.

I have real world example of abstraction that I plan to share with shortly but until that time I would love to hear your thoughts on this. I would also love to hear some more examples that you have come across that could help us. Before I move on to other OO concepts I want to bet this one to death so we can all really have it sink in. Again, my name is NOT  Hal Helms so I am not not an expert on the subject so please correct me where need be!