This is part 3 in the series “A Beginner’s Guide to Object-Oriented Programming with Apex” and will cover the aspect of Abstraction. For other posts in this series see the links below.

A Beginner’s Guide to Object-Oriented Programming with Apex

1. Introduction
2. Encapsulation
3. Abstraction (this post)
4. Polymorphism

What the hell is Abstraction?

Abstraction is a very interesting and surprisingly simple concept. At its core it’s about context and if Abstraction were a company it’s motto would be “Provide the right tools and data at the right time.”. There are many analogies in the “real world” e.g.

• The Force.com Platform is an abstraction of the complex, underlying hardware and software that provides us with a simplified set of tools that can achieve the same level of benefit as those complex, underlying hardware and software!
• A technical architect and developer both experience the creation of software but the developer’s perspective is far more detailed and requires different knowledge and tools. A technical architect has a different perspective and usually is not interested in the same information and tools that the developer needs. The detail of the developer’s work is abstracted from the technical architect although they will have a higher-level understanding of the same applications.
• The driver of the car has a very different perspective (interface, information, goals, tools) than the engineer of the same car. Imagine if you had to know how all the parts of a car work together in order to drive! Those details are abstracted from the driver.

Where is this applicable to developers on the platform? Ever created a Visualforce component or Apex utility class? Well you my friend you are already using abstraction!

This sounds a lot like Encapsulation!

Abstraction and Encapsulation go hand in hand but they are different. Encapsulation is one of the ways you can achieve abstraction but does not encompass the entire concept. As stated previously Encapsulation is about hiding data and logic-implementations whereas Abstraction is described as providing the appropriate perspective to the appropriate consumer.

How do we Abstract?

There is a lot that is already abstracted on the platform e.g. 

• The declarative features of the platform abstract the complexity that you would have to employ in order to replicate them through code.
• The mechanisms for CRUD access to data are abstracted through SObjects (using a technique called ORM) in order to simplify this access.
• Apex and Visualforce give you the ability to encapsulate and abstract complexity and expose this to consumers (other code and/orwebservices) through simplified interfaces.
  • These abstractions can be very sophisticated as has been shown several times on Andy Fawcett’s blog e.g. the domain, selector and service layer patterns in this repo provide patterns that allow the implementor to create simple mechanisms to connect and exercise complex logic. Those that use this logic need not be aware of the complexity contained beneath.

So how do you use abstraction? This is a topic that could take a year at University to teach but let me provide two examples, one simple and another more complex.

1. Simple Example

Calculating the area of a circle requires some specialised knowledge so you may want to create an abstraction of this calculation i.e. give other developers a way to calculate the area of a circle without having to know the actual calculation.

public Double calculateArea( Integer radius ) {

  return (radius)*(radius)*(Math.acos(-1)); // Pi = Math.acos(-1)

}

Obviously this is a very simple example but you could imagine a public method that is a lot more complex and whose inner workings you don’t really care to know too much about!

Note that this could also be used as an example of encapsulation! The difference however is that when considering this code as:

• Encapsulation ~ we are hiding the implementation.
• Abstraction ~ we are providing the appropriately simplified interface in order to access this functionality.

A subtle but important difference.

2. Complex Example

The complex examples considers a potential design pattern for your Apex code.

This example works at a higher level of abstraction than the previous one (pretty meta huh?) but the concept is similar. A developer creates a class (or set of classes) that contain all of complex business logic for the marketing department (this might be called your Service Layer if you were layering your application logic). This logic is then consumed by several other platform components such as trigger handlers, page controllers and bulk apex classes. The class methods and properties expose simplified interfaces to this logic and the details of the logic are abstracted from the consumers.

The benefit of abstraction here is that (in theory) you don’t need understand the details of the logic within the business logic classes you just need to understand their general purpose, know the method signature for the appropriate method and if necessary pass it the right data to get the expect result. And

Why Should I Use Abstraction?

If you’re a developer – much as with Encapsulation – you’ve probably been using Abstraction without even knowing it. The benefits are that by employing abstraction you’re making things easier for you and your team by presenting only the relevant information and tools at the appropriate time. This means a less confusing world, so less time is spent comprehending an application, fewer errors are made and everyone is happier.

Next time I’ll talk about my favourite part of these OOP principles, Polymorphism. It’s more than just a fun word to say!