7 C++ Inheritance Nightmares Rust Fixes Forever

in Blog / Rust Dev , Tags: C++, Rust
7 C++ Inheritance Nightmares Rust Fixes Forever

Seven ways C++ inheritance can create issues, and how Rust’s composition model fixes them all. From diamond problems to fragile base classes, see why composition wins in the long run.

Why Your Code Keeps Breaking (And How Rust Fixes It)

Picture this: You’re three weeks into debugging a critical system. The symptoms are bizarre—your hybrid sensor driver crashes randomly, but only when you initialize both interfaces. You’ve checked the documentation twice. Your configuration looks correct. The timing seems fine.

Then you see it: error: ambiguous call to init().

Your sensor class inherits from both I2CInterface and SPIInterface. Both inherit from Device. You’ve got two copies of the base class, and C++ has no idea which init() method to call. Welcome to the diamond problem—and it’s just the first of seven inheritance nightmares that plague C++ codebases everywhere.

Here’s the thing: inheritance in C++ comes with real trade-offs that can become more painful as codebases grow, especially when architecture decisions weren’t considered upfront. Whether you’re building web services, desktop applications, game engines, or embedded systems, certain patterns keep causing headaches. Rust takes a different approach—

  • favoring composition through structs
  • behavior through traits
  • variants through enums.

Let’s dive into seven common inheritance pitfalls and see how Rust’s model avoids them.

Nightmare #1: The Diamond Problem (Multiple Inheritance Ambiguity)

The C++ Nightmare

Multiple inheritance creates ambiguity when two parent classes share a common ancestor. Your compiler can’t decide which method to call. This affects game entity systems, data processing pipelines, and just about any complex inheritance hierarchy.

graph TD
    A[Device] --> B[NetworkDevice]
    A --> C[StorageDevice]
    B --> D[HybridCache]
    C --> D
    style D fill:#ff6b6b
    style A fill:#ffd93d
    classDef problem fill:#ff6b6b
    classDef base fill:#ffd93d

// Generic example - applies to any domain
class Device {
public:
    virtual void init() { /* configure resources */ }
};

class NetworkDevice : public Device { 
    // Inherits Device::init()
};

class StorageDevice : public Device { 
    // Also inherits Device::init()
};

// Hybrid cache using both network and storage
class HybridCache : public NetworkDevice, public StorageDevice {
    void setup() {
        init();  // ERROR: Which one?!
        // Compiler: "Ambiguous call to init()"
    }
};

This can kill a distributed caching system. The initialization sequence fails silently. Where the network is configured but storage doesn’t. The cache returns stale data for weeks before anyone notices it’s only using memory.

In STM32 firmware, this same pattern appears when devices use multiple bus interfaces. A sensor with both I2C and SPI interfaces inheriting from I2CDevice and SPIDevice creates the exact same ambiguity—except now your hardware isn’t initializing correctly.

The Rust Fix

Traits define behavior without inheriting state. No shared ancestors means no ambiguity.

What are Traits? (For C++ Developers)

If you’re coming from C++, think of traits as pure abstract classes with no data members—like interfaces in Java or C#. A trait declares method signatures that types must implement, but it never carries state.

Key differences from C++ abstract classes:

  • No state inheritance: Traits only define behavior, never fields. No hidden base class data.
  • No vtable by default: Trait methods use static dispatch (monomorphization) unless you explicitly opt into dynamic dispatch with dyn Trait.
  • Multiple traits, no diamond: A struct can implement many traits without ambiguity—there’s no shared ancestor to conflict.
  • Implement anywhere: You can implement a trait for a type you didn’t write (with some restrictions), enabling extension without inheritance.
// C++ abstract class equivalent:
// class Printable { public: virtual void print() = 0; };

// Rust trait:
trait Printable {
    fn print(&self);  // No body = must implement
}

Traits separate what a type can do from what data a type holds—a much cleaner approach than inheritance.

// Clean, unambiguous composition
trait Initializable {
    fn init(&mut self);
}

struct NetworkDevice { /* network config */ }
struct StorageDevice { /* storage config */ }

struct HybridCache {
    network: NetworkDevice,  // Has-a relationship
    storage: StorageDevice,  // Not is-a!
}

impl Initializable for HybridCache {
    fn init(&mut self) {
        self.network.init();  // Explicit
        self.storage.init();  // Clear
    }
}

Rust uses composition (has-a) instead of inheritance (is-a). You explicitly control which components initialize and in what order. No compiler guessing games.

graph LR
    A[HybridCache] --> B[NetworkDevice]
    A --> C[StorageDevice]
    style A fill:#51cf66
    style B fill:#51cf66
    style C fill:#51cf66
    classDef safe fill:#51cf66

Each component is independent, no ambiguity.

Nightmare #2: Fragile Base Class Syndrome

The C++ Nightmare

What this really means: In inheritance hierarchies, child classes depend on the implementation details of their parent classes. When you modify the base class—even seemingly innocent changes like adding a field or changing initialization order—you can silently break every derived class in ways that won’t show up until runtime. This creates a ripple effect where one “simple” change cascades through dozens of classes.

Change one line in a parent class, break dozens of child classes. This happens in game engines, GUI frameworks, business logic layers—anywhere inheritance is used.

graph TD
    A[Connection<br/>Base Class] --> B[HTTPConnection]
    A --> C[WebSocketConnection]
    A --> D[DatabaseConnection]
    A --> E[...20+ more]
    A -.->|"Add timeout field"| F[💥 ALL BREAK]
    style A fill:#ff6b6b
    style F fill:#ff6b6b
    classDef danger fill:#ff6b6b

One change to the base class ripples to every derived class. Silent breakage.

class Connection {
protected:
    std::string host;  
    int timeout;  // Added for "optimization" - whoops!
public:
    virtual void connect();
};

// These all break instantly
class HTTPConnection : public Connection { /* compilation error */ };
class WebSocketConnection : public Connection { /* broken */ };
class DatabaseConnection : public Connection { /* also broken */ };
// + 20 more connection types now failing builds

Real-world impact: A web framework maintainer added connection pooling to the base Connection class “for performance.” It broke every single protocol implementation in the codebase. The fix took three days and delayed a major release.

Embedded angle: In STM32 HAL code, this is even more dangerous. A contractor added register caching to the GPIOBase class. It broke every peripheral driver—LEDs, buttons, PWM, everything. On a 72MHz STM32F1, you can’t afford these surprises.

The Rust Fix

Composition makes dependencies explicit. Changes don’t propagate silently.

struct Connection {
    host: String,
    timeout: u32,  // Add whatever you want
}

struct HTTPConnection {
    conn: Connection,  // Explicit dependency
}

// Changing Connection doesn't auto-break HTTPConnection
// Compiler tells you EXACTLY what needs updating
impl HTTPConnection {
    fn connect(&mut self) {
        self.conn.connect();  // Delegation is explicit
    }
}

Rust requires explicit delegation. When you change a struct, the compiler shows you exactly what needs updating. No silent breakage across inheritance trees.

graph TD
    A[Connection Struct] --> B[HTTPConnection]
    A --> C[WebSocketConnection]
    B -->|"explicit delegation"| D[conn.connect]
    C -->|"explicit delegation"| E[conn.connect]
    A -.->|"Add field"| F[Compiler shows<br/>what needs updating]
    style A fill:#51cf66
    style F fill:#51cf66
    classDef safe fill:#51cf66

Changes are explicit. The compiler tells you exactly what to update.

Nightmare #3: Virtual Dispatch Overhead (VTable Death)

The C++ Nightmare

What this really means: Virtual functions enable polymorphism by deferring the decision of “which function to call” until runtime. But this flexibility comes at a cost: every virtual function call requires looking up the correct function in a hidden table (vtable), then jumping to that address. In performance-critical code—game loops processing thousands of entities, data pipelines handling millions of records, or firmware running on constrained hardware—these extra memory accesses and unpredictable jumps accumulate into measurable overhead.

Virtual function calls use vtable lookups—an extra memory access and indirect jump on every call. This matters in game loops, data processing pipelines, and high-frequency trading systems.

When you use virtual functions in C++, the compiler creates a hidden table of function pointers (the vtable) for each class. Every object with virtual functions stores a hidden pointer to its class’s vtable. When you call entity->update(), the CPU must:

  1. Dereference the object to get the vtable pointer
  2. Look up the function pointer in the vtable
  3. Jump to that address (indirect jump)
  4. Possibly miss the CPU cache because the address wasn’t predictable

Each virtual call: 2-3 extra memory accesses + unpredictable jump = slower code.

class Entity {
public:
    virtual void update(float dt) = 0;  // Vtable lookup
};

void gameLoop(Entity* entities[], size_t count) {
    for(size_t i = 0; i < count; i++) {
        entities[i]->update(deltaTime);  
        // Each call: vtable lookup → indirect jump → cache miss?
    }
}

A game engine updated 10,000 entities per frame. Virtual dispatch added 5-7% CPU overhead. On a system targeting 60fps, this meant dropped frames and stuttering.

On a 72MHz STM32F1 reading 16 sensor channels at 1kHz, virtual dispatch added 3-5% CPU overhead. At 92% utilization, this caused missed samples and corrupted data logs.

The Rust Fix

Static dispatch through generics. The compiler generates specialized code for each type—zero runtime cost.

trait Entity {
    fn update(&mut self, dt: f32);
}

// Monomorphized at compile time - no vtable!
fn game_loop<T: Entity>(entities: &mut [T], dt: f32) {
    for entity in entities {
        entity.update(dt);  // Direct call, often inlined
    }
}

Rust uses static dispatch by default through monomorphization. When you write game_loop::<Player>(players, dt), the compiler creates a specialized version of the function specifically for Player. The call to entity.update(dt) becomes a direct function call—no vtable, no pointer chasing, no indirection.

graph LR
    A[entity.update<br/>call] --> B[Direct function<br/>call - inlined]
    B --> C[Actual<br/>function]
    style A fill:#51cf66
    style B fill:#51cf66
    style C fill:#51cf66
    classDef fast fill:#51cf66

Static dispatch: The compiler knows exactly which function to call. Often gets inlined completely.

Need runtime polymorphism? Rust has dyn Trait for that—but you opt-in explicitly:

// Explicit dynamic dispatch when you need it
fn update_mixed(entities: &mut [Box<dyn Entity>], dt: f32) {
    // Now using vtables, but you chose this explicitly
}

Rust defaults to static dispatch (zero cost). Need runtime polymorphism? Use dyn Trait explicitly. But for most code—games, services, firmware—you get performance for free.

Nightmare #4: Dangling Pointers (Lifetime Hell)

The C++ Nightmare

What this really means: When you use base class pointers to reference derived objects, the pointer itself doesn’t know or care about the lifetime of the actual object. If the object gets destroyed (goes out of scope, gets deleted, or the stack unwinds), but the pointer still exists, you now have a “dangling pointer”—a memory address that points to garbage. Dereferencing it is undefined behavior: sometimes crashes, sometimes corrupted data, sometimes “works” (the most dangerous case). This is especially insidious because the bug might only appear under specific timing conditions or memory states.

Base class pointers can outlive the derived objects they point to. Use-after-free bugs appear in web servers, desktop apps, and embedded systems alike.

sequenceDiagram
    participant F as createPlayer()
    participant S as Stack
    participant M as Main
    
    F->>S: Player allocated on stack
    F->>M: Return &player (pointer)
    F->>S: Function ends, stack freed! 💥
    M->>S: e->update() reads freed memory
    Note over M,S: 💀 Use-after-free!<br/>Undefined behavior

The pointer outlives the data it points to. Classic dangling pointer.

Entity* createPlayer() {
    Player player;  // Stack allocated
    return &player;  // BOOM: Returning address of local variable
}

void gameLoop() {
    Entity* e = createPlayer();
    e->update(deltaTime);  // Reading freed memory!
    // Sometimes works, sometimes crashes, always wrong
}

Real-world impact: A web framework returned stack-allocated request handlers. The pointer got reused. The HTTP router read random stack garbage and routed requests to the wrong endpoints—silent data leaks between user sessions.

Embedded angle: A pressure sensor driver returned a stack-allocated object. The pointer got reused for interrupt context data. The HVAC controller read random stack values and interpreted them as “pressure critical”—triggering emergency shutdowns on a manufacturing line.

The Rust Fix

The borrow checker prevents dangling references at compile time. This code won’t even build.

fn create_player() -> &Player {
    let player = Player::new();
    &player  // ERROR: "player does not live long enough"
}
// Compiler: "This code is unsafe. Fix it or don't ship."

Rust’s ownership system makes use-after-free impossible. If it compiles, the lifetimes are correct. No runtime checks, no performance cost, no undefined behavior.

sequenceDiagram
    participant F as create_player()
    participant C as Compiler
    
    F->>C: let player = Player::new()
    F->>C: return &player
    C-->>F: ❌ ERROR: "player does<br/>not live long enough"
    Note over F,C: ✅ Caught at compile time!<br/>No runtime crash possible

Rust’s borrow checker catches the bug before it ever runs.

Nightmare #5: Object Slicing (Silent Data Loss)

The C++ Nightmare

What this really means: When you pass a derived class object by value to a function expecting a base class, C++ performs an implicit conversion. But here’s the problem: the base class variable is smaller than the derived object. So the compiler “slices off” all the derived class’s additional data members to make it fit. No warning. No error. Your authentication tokens, calibration coefficients, or user IDs simply vanish. The code compiles and runs—it just silently loses data.

Assign a derived object to a base class variable, and the compiler silently discards the derived data. This bug is invisible until production, affecting logging systems, serialization, and data pipelines.

graph LR
    subgraph Input["AuthenticatedRequest"]
        A1[id: 1]
        A2[token: secret]
        A3[userId: 42]
    end
    
    subgraph Output["After logRequest"]
        B1[id: 1]
        B2[token: GONE]
        B3[userId: GONE]
    end
    
    A1 --> B1
    A2 -.->|sliced off| B2
    A3 -.->|sliced off| B3
    
    style B2 fill:#ff6b6b
    style B3 fill:#ff6b6b

Object slicing: Derived data silently vanishes when passed by value.

class Request {
    int id;
};

class AuthenticatedRequest : public Request {
    std::string token;  // THIS DATA MATTERS
    int userId;
};

void logRequest(Request r) {  // Pass by value - DANGER
    // token and userId are gone!
    // Sliced off, no warning, no error
}

AuthenticatedRequest req{1, "secret-token", 42};
logRequest(req);  // Data loss is silent

A logging system logged requests by base class. Authentication tokens were sliced off. The audit trail was incomplete. Security compliance failed because the logs couldn’t prove who made which requests.

Embedded angle: A calibration system logged sensors by base class. The calibration coefficients were sliced off. Every temperature reading was wrong by 2-3°C. The bug survived code review and testing because it compiled without warnings.

The Rust Fix

No implicit upcasting. Type conversions must be explicit and intentional.

struct Request { id: i32 }

struct AuthenticatedRequest { 
    request: Request,
    token: String,
    user_id: i32,
}

fn log_request(r: Request) { /* ... */ }

let auth_req = AuthenticatedRequest { 
    request: Request { id: 1 },
    token: "secret-token".to_string(),
    user_id: 42,
};

// log_request(auth_req);  // ERROR: Type mismatch
log_request(auth_req.request);  // Must be explicit!

Rust prevents accidental data loss. Want to extract the base data? Write it explicitly. No silent slicing, ever.

graph LR
    subgraph AuthReq["AuthenticatedRequest"]
        A1[request: Request]
        A2[token: String]
        A3[user_id: i32]
    end
    
    A1 -->|"explicit: auth_req.request"| B[log_request]
    A2 -.->|"Cannot pass whole struct"| B
    A3 -.->|"Type mismatch error"| B
    
    style B fill:#51cf66

Rust requires explicit field access. No accidental data loss possible.

Nightmare #6: Constructor Complexity (Init Order Hell)

The C++ Nightmare

What this really means: In C++, base class constructors always execute before derived class constructors—you can’t control this order. This creates a chicken-and-egg problem: what if the base class needs configuration that the derived class loads? What if initialization can fail, but constructors can’t return errors elegantly (without exceptions)? What if initialization steps have interdependencies that don’t align with the rigid base-first order? You end up with initialization flags, global state, multi-phase initialization patterns, and error handling gymnastics—all because the language forces a specific execution order.

Complex initialization sequences fail in subtle ways. Base constructors run first, creating rigid ordering requirements and error handling nightmares. This affects frameworks, database connections, and resource managers.

sequenceDiagram
    participant D as DatabaseConnection()
    participant C as Connection()
    participant S as initSocket()
    participant L as loadConfig()
    
    D->>C: Base constructor runs FIRST
    C->>S: initSocket()
    Note over S: What if this fails?<br/>No return value!
    C-->>D: Base initialized
    D->>L: loadConfig()
    Note over L: Needs socket params<br/>but socket init failed!
    Note over D: 💥 Chicken-and-egg problem<br/>No clean error handling

Constructor ordering is rigid. Error handling is painful. Dependencies are implicit.

class Connection {
public:
    Connection() { 
        initSocket();  // MUST happen first
        // But what if this fails?
    }
};

class DatabaseConnection : public Connection {
    Config config;
public:
    DatabaseConnection() : Connection(), config(loadConfig()) {
        // Problems:
        // 1. What if initSocket() fails?
        // 2. What if loadConfig() needs an active socket?
        // 3. No way to return errors from constructors
        // 4. Exception handling? Not in all environments
    }
};

Real-world impact: A database ORM initialized connections before loading configuration. But the configuration specified connection parameters. Classic chicken-and-egg. The workaround involved global state and init flags—technical debt that lasted years.

Embedded angle: A smart thermostat’s base class initialized I2C before derived classes loaded configuration. But the configuration was stored on an I2C EEPROM. The fix required global state and multiple initialization phases—brittle code that failed under edge cases.

The Rust Fix

Struct fields initialize cleanly with explicit builders and proper error handling.

struct Connection {
    socket: Socket,
}

impl Connection {
    fn new() -> Result<Self, Error> {
        let socket = Socket::init()?;  // Explicit, fallible
        Ok(Connection { socket })
    }
}

struct DatabaseConnection {
    conn: Connection,
    config: Config,
}

impl DatabaseConnection {
    fn new() -> Result<Self, Error> {
        let config = Config::load()?;  // Load first
        let conn = Connection::new()?;  // Then connect
        Ok(DatabaseConnection { conn, config })
    }
}

Builders make initialization explicit and composable. Errors are values, not exceptions. Dependencies are clear. No hidden constructor chains, no initialization order surprises.

sequenceDiagram
    participant D as DatabaseConnection::new()
    participant C as Config::load()
    participant N as Connection::new()
    
    D->>C: Config::load()?
    alt Config fails
        C-->>D: Err(ConfigError)
        D-->>D: Return early with error
    else Config succeeds
        C-->>D: Ok(config)
    end
    D->>N: Connection::new()?
    alt Connection fails
        N-->>D: Err(ConnectionError)
        D-->>D: Return early with error
    else Connection succeeds
        N-->>D: Ok(conn)
    end
    Note over D: ✅ Explicit order<br/>✅ Clean error handling<br/>✅ No hidden chains

You control the order. Errors are explicit values. No surprises.

Nightmare #7: Tight Coupling (Hierarchy Hell)

The C++ Nightmare

What this really means: Inheritance forces you to organize code into a tree structure: every class has exactly one parent (or multiple in the case of multiple inheritance, which brings its own problems). This seems logical at first, but becomes a straitjacket as requirements evolve. Want to add logging? It needs to go in the base class (affecting everything) or in every leaf class (code duplication). Want a component to gain behavior from two unrelated hierarchies? Can’t do it cleanly. The tree structure that seemed natural on day one becomes a rigid prison that resists change.

Inheritance creates rigid trees. Want to add a feature? Modify the base class and break everything, or duplicate code in every child class. This affects plugin systems, middleware, and device drivers.

graph TD
    A[Component] --> B[RenderComponent]
    A --> C[PhysicsComponent]
    A --> D[AudioComponent]
    A --> E[NetworkComponent]
    B --> F[AnimatedSprite]
    C --> G[RigidBody]
    style A fill:#ff6b6b
    A -.->|Change breaks all| B
    A -.->|Change breaks all| C
    A -.->|Change breaks all| D
    A -.->|Change breaks all| E
    classDef danger fill:#ff6b6b

Inheritance tree: Every change to the root ripples down. Rigid and fragile.

class Component {
    virtual void update(float dt);
    virtual void render();
    // Want to add debug visualization later? Good luck.
};

class RenderComponent : public Component {
    // 200 lines of rendering logic
};

class PhysicsComponent : public Component {
    // 300 lines of physics logic
};

// Six months later: "We need debug visualization"
// Option A: Modify base class → break 12 component types
// Option B: Add to each child → copy-paste nightmare
// Option C: Cry

Real-world impact: A game engine needed profiling hooks in all components. Adding them to the base class broke three component types that didn’t support profiling. Adding them separately to each child led to eight different implementations with subtly different bugs.

Embedded angle: A robotic arm controller needed emergency stop functionality. Adding it to the MotorController base class broke three motor drivers that didn’t support braking. Adding it to each child separately led to five different implementations with subtly different timing bugs.

The Rust Fix

Traits and enums enable flexible composition without coupling.

trait Component {
    fn update(&mut self, dt: f32);
    fn render(&self);
}

trait Debuggable {
    fn debug_draw(&self);
}

// Mix and match traits freely!
struct RenderComponent { /* ... */ }
impl Component for RenderComponent { /* ... */ }
impl Debuggable for RenderComponent { /* ... */ }  // Add later, no drama

struct PhysicsComponent { /* ... */ }
impl Component for PhysicsComponent { /* ... */ }
// Physics doesn't need Debuggable? Don't implement it!

// Or use enums for known variants
enum GameComponent {
    Render(RenderComponent),
    Physics(PhysicsComponent),
    Audio(AudioComponent),
}

impl GameComponent {
    fn update(&mut self, dt: f32) {
        match self {
            GameComponent::Render(r) => r.update(dt),
            GameComponent::Physics(p) => p.update(dt),
            GameComponent::Audio(a) => a.update(dt),
        }
    }
}

Traits let you add behavior without touching existing code. Enums give you exhaustive pattern matching—the compiler ensures you handle every variant. No rigid hierarchies, just flexible composition.

graph LR
    A[Component Trait] -.->|implements| B[RenderComponent]
    A -.->|implements| C[PhysicsComponent]
    A -.->|implements| D[AudioComponent]
    E[Debuggable Trait] -.->|implements| B
    E -.->|implements| C
    F[Serializable Trait] -.->|implements| B
    F -.->|implements| D
    style A fill:#51cf66
    style E fill:#51cf66
    style F fill:#51cf66
    classDef flexible fill:#51cf66

Mix and match behaviors independently. Add traits without breaking existing code.

The Rust Replacement Strategy

Rust doesn’t patch inheritance—it replaces it with three better tools:

  1. Structs for “has-a” relationships (composition instead of inheritance)
  2. Traits for “does-it” behavior (interfaces without state baggage)
  3. Enums for “is-one-of” variants (algebraic types with exhaustive matching)
graph TD
    subgraph "C++ Inheritance Model"
    A1[Base Class] -->|is-a| B1[Derived Class]
    A1 -->|vtable| C1[Virtual Functions]
    A1 -->|state| D1[Inherited Fields]
    style A1 fill:#ff6b6b
    end
    
    subgraph "Rust Composition Model"
    A2[Struct] -->|has-a| B2[Other Structs]
    A2 -->|implements| C2[Traits]
    A2 -->|or is| D2[Enum Variant]
    style A2 fill:#51cf66
    end

Fundamentally different philosophies: Inheritance vs. Composition.

This applies everywhere—from web services to embedded firmware. The seven nightmares appear everywhere inheritance is used. The Rust solutions work everywhere too.

Your Refactoring Checklist (Works Anywhere)

Ready to escape inheritance hell? Here’s how to start:

  1. Identify inheritance hierarchies in your codebase
  2. Convert “is-a” to “has-a” — replace inheritance with composition
  3. Extract interfaces as traits — behavior without state inheritance
  4. Use enums for variants — replace hierarchies with algebraic types

Example 1: Web Service Refactor

// Before: Database connection inheritance nightmare
// class PostgresConnection : public Connection { ... }
// class MySQLConnection : public Connection { ... }

// After: Clean composition
trait Database {
    fn query(&mut self, sql: &str) -> Result<Rows>;
    fn execute(&mut self, sql: &str) -> Result<()>;
}

struct PostgresConnection {
    pool: ConnectionPool,
    config: PostgresConfig,
}

impl Database for PostgresConnection {
    fn query(&mut self, sql: &str) -> Result<Rows> {
        self.pool.get()?.query(sql)
    }
}

// No vtables, no ambiguity, no fragile base classes

Example 2: STM32 Firmware Refactor

Now let’s see how this same philosophy transforms embedded code:

// Before: STM32 HAL inheritance nightmare
// class USART : public Peripheral { ... }
// class USART_DMA : public USART { ... }

// After: Clean composition with same benefits
trait PeripheralControl {
    fn enable(&mut self);
    fn disable(&mut self);
}

struct USART {
    registers: UsartRegisters,
    dma: Option<DMAChannel>,  // Optional composition!
}

impl PeripheralControl for USART {
    fn enable(&mut self) { 
        self.registers.cr1.modify(|_, w| w.ue().set_bit());
    }
    fn disable(&mut self) { 
        self.registers.cr1.modify(|_, w| w.ue().clear_bit());
    }
}

graph LR
    A[USART Struct] --> B[UsartRegisters]
    A --> C[Option DMAChannel]
    A -.->|implements| D[PeripheralControl Trait]
    A -.->|implements| E[Read Trait]
    A -.->|implements| F[Write Trait]
    style A fill:#51cf66
    style D fill:#74c0fc
    style E fill:#74c0fc
    style F fill:#74c0fc

USART owns its components, implements multiple independent traits. No inheritance needed.

The pattern is identical whether you’re building web APIs or firmware. The seven nightmares appear everywhere inheritance is used. The Rust solutions work everywhere too.

Why Composition Wins in the Long Run

Inheritance has its place, but over time, composition-based architectures prove more maintainable. Here’s how Rust’s approach pays dividends:

  • Diamond problems? Traits can’t inherit state—no ambiguity.
  • Fragile base classes? Composition makes changes explicit and localized.
  • Virtual dispatch overhead? Static dispatch gives you zero-cost abstractions.
  • Dangling pointers? The borrow checker catches them at compile time.
  • Object slicing? No implicit upcasting means no silent data loss.
  • Constructor hell? Builders and Results handle errors gracefully.
  • Tight coupling? Traits and enums compose freely without rigid hierarchies.

Whether you’re building web backends, desktop apps, game engines, or embedded firmware, favoring composition over inheritance leads to code that’s easier to extend, test, and refactor.

These patterns scale better as codebases grow. What starts as a simple inheritance tree often becomes a maintenance burden—adding features requires modifying base classes, which risks breaking derived types. Composition avoids this cascade effect.