Learn C++ - Architecture & Design Patterns

#Introduction

After you've mastered the syntax and STL, the next question is: how do you structure a large program so it stays maintainable? The answer is architecture and design patterns — proven solution patterns for recurring problems.

Episode 17 covers the most relevant patterns for C++: factory and singleton for object creation, observer for communication between components, dependency injection and adapter to reduce coupling, decorator to extend behavior, as well as layered architecture and modularization for organizing large-scale projects.

#Factory and Singleton

#Factory Method

A factory centralizes object creation logic, so the caller doesn't need to know which concrete class is created. In modern C++, a factory usually returns std::unique_ptr to an interface:

cat > factory.cpp <<'EOF'
#include <iostream>
#include <memory>
 
class Bentuk {
public:
    virtual ~Bentuk() = default;
    virtual void gambar() const = 0;
};
 
class Lingkaran : public Bentuk {
public:
    void gambar() const override { std::cout << "Lingkaran\n"; }
};
 
class Persegi : public Bentuk {
public:
    void gambar() const override { std::cout << "Persegi\n"; }
};
 
std::unique_ptr<Bentuk> buat_bentuk(const std::string& tipe) {
    if (tipe == "lingkaran") {
        return std::make_unique<Lingkaran>();
    }
    return std::make_unique<Persegi>();
}
 
int main() {
    auto b = buat_bentuk("lingkaran");
    b->gambar();
}
EOF
g++ -std=c++20 factory.cpp -o factory
./factory

buat_bentuk("lingkaran") returns a std::unique_ptr<Bentuk> — the caller depends on the interface, not a concrete class. Adding a new shape type doesn't change the caller's code.

#Singleton, Used Carefully

A singleton guarantees only one global instance. In modern C++, use a function-local static, which is thread-safe since C++11:

cat > singleton.cpp <<'EOF'
#include <iostream>
#include <string>
 
class Konfigurasi {
public:
    static Konfigurasi& instance() {
        static Konfigurasi cfg;
        return cfg;
    }
 
    void set_nama(const std::string& n) { nama_ = n; }
    std::string nama() const { return nama_; }
 
private:
    Konfigurasi() = default;
    std::string nama_ = "default";
};
 
int main() {
    Konfigurasi::instance().set_nama("produksi");
    std::cout << Konfigurasi::instance().nama() << "\n";
}
EOF
g++ -std=c++20 singleton.cpp -o singleton
./singleton

static Konfigurasi cfg inside the function creates an instance initialized once and thread-safe. Singletons are useful for global configuration, but use them wisely — hidden state makes unit testing hard.

#Observer

#Notifying Many Listeners

Observer lets one object notify many other objects when a change happens, without them knowing each other. The subject stores a list of observers, and s.tambah(&log) registers an observer. When the value changes, s.set_nilai(42) triggers update on all registered observers. Note the non-owning observation pointers — std::weak_ptr is a safer alternative.

#Dependency Injection, Adapter, and Decorator

#Dependency Injection

Dependency injection passes dependencies through the constructor instead of creating them inside the class. The constructor Layanan(std::shared_ptr<Penyimpan> p) receives the dependency from outside. This makes testing easier — in unit tests, swap PenyimpanFile for a fake implementation without changing Layanan.

#Adapter and Decorator

Adapter converts one interface into another so incompatible components can still work together. Decorator wraps an object to add behavior without changing the original class. Both use composition: wrap the object and forward calls while adding logic.

#Layered Architecture and DDD

#Separating Concerns

Layered architecture divides an application into layers: presentation, application, domain, and infrastructure. Each layer only depends on the one below it. The result is code that's easier to test, and technology changes in one layer don't shake up the others.

Domain-driven design (DDD) centers business logic in the domain layer, which is free of frameworks and databases. Entities and value objects model business rules, while repositories in infrastructure handle storage. Business rules can then be tested without a database.

Large projects are split into directories that reflect the architecture:

src/
  domain/      # entities and business logic
  application/ # use cases and services
  infrastructure/ # database, network, logging
  presentation/   # API or CLI

The structure src/domain, src/application, src/infrastructure, src/presentation separates layers at the directory level. Dependencies always point from the outside in — presentation may use domain, but domain must not know about presentation.

#Modularization and Large-scale Organization

#Modules and Libraries

At large scale, code is split into libraries and executables. CMake manages this with add_library and target_link_libraries. Each library has a small public interface and a private implementation:

cat > CMakeLists.txt <<'EOF'
cmake_minimum_required(VERSION 3.20)
project(arsitektur LANGUAGES CXX)
 
add_library(domain STATIC
    src/domain/entitas.cpp
    src/domain/repository.cpp)
 
add_executable(app src/main.cpp)
target_link_libraries(app PRIVATE domain)
target_compile_features(domain PUBLIC cxx_std_20)
EOF
cmake -S . -B build
cmake --build build

add_library(domain STATIC ...) builds a static library from the domain files, and target_link_libraries(app PRIVATE domain) links it to the executable. target_compile_features(domain PUBLIC cxx_std_20) sets C++20 as the standard for the library and its users. This pattern keeps module boundaries firm.

#Conclusion

Here's what to take away:

• Factory centralizes object creation and returns an interface.
• Thread-safe singletons use function-local statics; use them sparingly.
• Observer connects changes to many listeners without them knowing each other.
• Dependency injection makes testing easier through the constructor.
• Adapter and decorator extend interfaces and behavior via composition.
• Layered architecture and libraries separate concerns and module boundaries.

In the next episode, episode 18, we'll discuss system programming and low-level integration — interaction with system calls and operating system APIs, creating processes with fork and pipes for IPC, memory-mapped files, low-level I/O, as well as embedded systems basics and bare-metal considerations.