Class Abstraction and Encapsulation

We’ve talked about abstraction before when working with functions. The idea being using a simple to remember name, to hide a (potentially) complex process involving lots of steps.

Classes are often used in the same way. They should be thought of as a “black box” which the programmer doesn’t need to worry about how the data is stored, or the methods work. The programmer using the class should only worry about the data being sent to the class and/or method, and the data being returned.

This way, teams can work together with each member performing their own task. Then as they learn new things, they can update the class, without any changes for the end developer. This process is called refactoring.

Let’s consider an example from the past couple of weeks. We looked at how to perform a selection sort. Let’s say as a developer you wrote a class and used this sorting algorithm. Then later on you learn that it’s not real efficient, so you updated it to a quick sort, or heap sort – both of which are faster. Well, the end developer who is using your class should just be able to still call the sort() method, and have it work. They fact that you changed how it works shouldn’t matter.

Class Abstraction and Encapsulation was originally found on Access 2 Learn