When talking about Object Oriented Programming, sooner or later you will come across the ‘Pillars of OO’ or differently put, the basic principles that form the basics Object Oriented Programming. Well at least to some. There are many opinions and scientific papers on the subject of Object Oriented Programming and its ‘pillars’. I will leave all that in the middle as I want to expand a bit more on the concept of abstraction.
Abstraction is sometimes mentioned when people are talking or writing about the ‘Pillars of Object Oriented Programming” and sometimes it is not mentioned at all. I don’t know exactly why and frankly, I don’t really care either. What follows is my interpretation of abstraction and why I think it is important when designing software systems.
What is abstraction?
An abstraction is a simple representation of something real. And with a simple representation of something, I mean that we stripped that “something” of all details until only those remain that define it. It is making something more general instead of specifying it by removing all the details that do not matter. Or to say it in the words of Uncle Bob : “An abstraction contains the truths that do not change when the details change”.
Let’s take the picture on the left as an example. It is the silhouet of a man. That is an abstraction. It shows the essential characteristics of a human being: a head with a body, 2 arms and 2 legs, walking up straight and because of the posture, most people will likely say it is a man. It is missing details like skin color, haircut, color of the eyes and so on. But we can still tell that this is the silhouet of a man.
Making an abstraction of something is the process of reducing it to its essential qualities by leaving out the details that do not matter.
Why is abstraction important?
We make abstractions of things or processes from the real world because it makes it easier to reason about it. By making abstractions of the things in a problem domain, we can easier reason about the problem and thus it is easier to construct a fitting solution. This is what we do as developers. We create models in code using classes, functions or structs in order to reason about problems and create solutions for them.
To me, abstractions and the process of making abstractions is a very important part of software design. I see the process of abstraction as modelling. It is all about making accurate, reliable code units or code models for your solution. Sometimes developers screw up already when abstracting. Their abstractions aren’t accurate or they reuse an abstraction in different contexts, ending up with way too many details and behaviour. This can easily lead to confusion and data pollution.
As an example, consider the following situation: You have created a CMS for websites. You system deals with customers but it can also have different types of users, for example an admin user who can manage functionalities or a copywriter, who has only permission to change content. You might think of user and customers as persons. So you model model them as persons:
public class Person {
private String firstName;
private String lastName;
private String email;
private String phoneNumber;
private String streetName;
private String houseNumber;
private String city;
private Order lastPurchase;
private String[] permissions;
private Audit lastChanges;
private String username;
}
This is a bad abstraction / model. When this ‘Person’ class represents a customer, it doesn’t need to know about permissions, a username or have an audit trail of the last changes. And when it represents a user, it is confusing to have an empty field of ‘last purchases’.
Also, empty fields tend to be excellent candidates for ‘abuse’, filling them with data that shouldn’t be there. Imagine that all of sudden it is required to track some of the behaviour of customers and things need to go fast. It is not entirely unlikely that somebody comes up with the idea to put that information in the ‘lastChanges’ field. For customers this fields is empty anyway, right? Really, don’t do this, it is a very bad idea!
The above was just a silly example. But it is a fact that deciding which attributes or which methods a class should have, is not easy. And the more complex the system is you are building, the more important it is for your models to be correct and reliable (with reliable I mean that the fields contain the expected information). The GRASP principles are a set of guidelines which will help you with deciding which methods a class should have and there will be future posts where I go in depth.
Important to remember
- An abstraction is a representation of something but stripped from its details.
- It helps us to reason about problems and solutions
- Complex systems require accurate and reliable models / abstractions
That was it! Enjoyed this read? Critical thoughts? Don’t be afraid to reach out on linkedIn :).