Why Mastering Abstraction Is the Real Skill Behind Great Software Design

Abstract

Abstraction is the process of extracting the essential, common characteristics of a set of things while discarding non‑essential details. In software development it underpins object‑oriented design and guides the transformation from business requirements to code.

Step 1 – Analyze the Problem Domain

Begin by applying Object‑Oriented Analysis (OOA) to understand the real business needs. This requires logical reasoning, summarisation, and judgement to identify the core entities, relationships, and behaviours that the system must support.

Step 2 – Abstract Core Concepts

Translate the domain description into concrete concepts. Typical examples include:

Order : defines order attributes, relationships to customers, items, and lifecycle methods.

Money : encapsulates amount, currency, and conversion logic instead of using a raw BigDecimal.

Abstraction is iterative; analysis and concept extraction often occur in parallel.

Step 3 – Model the Problem Domain

Use Domain‑Driven Design (DDD) techniques such as event‑storming and a ubiquitous language to create a shared model. Common modelling tools are UML and BPMN. The model typically consists of three layers: business concepts, domain services, and infrastructure contracts.

Step 4 – System Design and Implementation

Apply the abstracted concepts to design concrete classes, interfaces, and services, then implement them with object‑oriented programming. The design should respect the evaluation criteria described below.

Evaluating an Abstraction

An adequate abstraction satisfies four quality attributes:

Coupling : minimise dependencies between packages or services so they can evolve independently.

Cohesion : group related responsibilities within the same class or module.

Sufficiency : capture the minimal yet complete set of features; removing any feature would break the concept.

Completeness : expose necessary operations without over‑design. For example, an add(E element) method should not be duplicated by a specialised add4() method; higher‑level behaviour can be composed from the basic operation.

Common Abstraction Problems in Code

Code duplication : Utility classes that aggregate unrelated methods increase coupling and hinder maintenance. Instead, extract meaningful domain entities (e.g., a Whitelist object) and keep utilities focused.

Missing abstraction (primitive obsession) : Representing money as a plain BigDecimal loses currency information. Encapsulate amount and currency in a Money value object with conversion methods.

Over‑abstraction : Merging distinct business domains (e.g., different order centers) into a single model creates superficial reuse without real benefit.

SLAP – Single Level of Abstraction Principle

Elements at the same abstraction level should be compared only with peers. Mixing levels (e.g., using a generic Map as a method parameter) erodes domain semantics and raises cognitive load.

Applying the SLAP Principle at Work

The same abstraction mindset can improve clarity in non‑technical tasks.

MECE Principle (Mutually Exclusive, Collectively Exhaustive)

In the Pyramid Principle, MECE ensures that categories are both exhaustive and independent, mirroring the need for uniform abstraction levels.

Work Breakdown Structure (WBS) in Project Management

Tasks are decomposed into a tree where each level maintains a consistent abstraction, ensuring clear responsibility and scope.

PPT Reporting – Abstract then Concrete

Effective presentations start with a concise headline (the abstract) and then expand with details, mirroring the abstraction process in software design.

Conceptual Thinking – Executive Capability

Senior leaders focus on high‑level concepts, while operational staff work with concrete details. Maintaining a single level of abstraction across a team reduces misunderstanding and eases maintenance.