- References
- Function Overloading
- Default Function Arguments
- Inline Function
- Dynamic Memory Allocation
- Placement New
- nullptr
- Namespaces
- Type Aliases
- Enum classes
- constexpr
- static_assert
- mutable Keyword
- auto Keyword
- Smart Pointers
- Basics of Classes
- Constructors
- Destructors
- Operator Overloading
- Copy Semantics
- Move Semantics
- Composition, RAII & Ownership
- Inheritance
- Polymorphism
- Abstraction
- Encapsulation
- Template
- Static Memory
- Friend Function
- this Pointer
- Function Pointer
- Lambdas and Callback Management
- Union
Abstraction (Hiding Complexity)

Abstraction is the process of exposing only the essential features of an object while hiding the complex implementation details ("the wiring") from the user.
Think of a Car:
- Abstraction (Interface): Steering wheel, pedals, gear stick. (What the user sees).
- Implementation (Hidden Details): Fuel injection timing, combustion cycles, differential gears. (What happens inside).
In C++, we achieve this using Access Specifiers (public/private) and Abstract Classes (Interfaces).
Syntax & Usage
1. Data Abstraction (The Public API)
Designing a class where the user sees simple functions, but the complex logic happens privately.
class WiFiModule {
private:
// Complex hidden details (User doesn't need to see these)
void spi_write(uint8_t byte) { /* ... */ }
void handshake_tcp() { /* ... */ }
int socket_id;
public:
// Simple Abstraction (User sees only this)
void connect(const char* ssid, const char* pass) {
spi_write(0x01); // Internal logic
handshake_tcp(); // Internal logic
}
};
int main() {
WiFiModule wifi;
// The user calls one simple function.
// They don't know (or care) that it triggered 50 SPI transactions.
wifi.connect("HomeNet", "1234");
}
2. Abstract Classes (Pure Interfaces)
Defining a blueprint that enforces what a device must do, without defining how.
// Abstract Base Class
class IMotor {
public:
virtual void setSpeed(int speed) = 0; // Pure Virtual
virtual void stop() = 0;
};
// The user code works with the "IMotor" abstraction,
// ignoring whether it's a DC Motor or Stepper Motor.
void emergency_shutdown(IMotor* m) {
m->stop();
}
Abstraction vs. Encapsulation
These two are often confused but are distinct.
| Feature | Encapsulation | Abstraction |
|---|---|---|
| Focus | Information Hiding. | Implementation Hiding. |
| Goal | Protect data from external corruption. | Reduce complexity for the user. |
| Mechanism | Getters/Setters, private variables. | Interfaces, Abstract Classes. |
| Analogy | The plastic casing around a wire. | The simple "On/Off" switch. |
Relevance in Embedded/Firmware
1. HAL (Hardware Abstraction Layer)
This is the textbook definition of abstraction in firmware.
You write code like GPIO_Write(PIN_5, HIGH).
- Abstraction: "Set Pin 5 High".
- Implementation: On AVR, this writes to
PORTB. On STM32, it writes toBSRRregister. On Linux, it writes to a file /sys/class/gpio. Your application logic relies on the abstraction, making it portable.
2. Reducing Cognitive Load
A Junior Developer can use a complex driver (e.g., a FAT32 filesystem wrapper) by just calling file.open() and file.write(). They don't need to understand sectors, clusters, or allocation tables to use it effectively.
Common Pitfalls (Practical Tips)
| Pitfall | Details |
|---|---|
| ❌ Leaky Abstractions | When implementation details "leak" out. Example: A generic |
| ❌ Over-Abstraction | Creating wrappers around wrappers (Driver -> Hal -> LL -> Register). Too many layers add overhead and make debugging harder ("Spaghetti Code"). Keep it flat where possible. |
| ✅ Design from the User's View | When writing a class, write the main() code first (how you want to use it). Then implement the class to match that simple API. |
Concept understood? Let's apply and learn for real