Bridging Object-Oriented and Functional Thinking in Modern C++

Source: Dev.to

How dependencies make C++ systems hard to test and evolve — and why functional thinking changes it

Fighting complexity is crucial if you want to succeed in software development. In many real‑world C++ projects, however, systems tend to evolve in the opposite direction.

• Tight coupling – components become tightly coupled, so changes ripple through large parts of the system.
• Scattered state – state is spread across the object graph, reducing transparency about how it evolves over time.
• Emergent behavior – behavior emerges from many interacting parts, making it hard to reason about individual pieces in isolation.

These characteristics also show up in testing: a significant amount of boilerplate and indirection is needed just to enable it. Establishing specific system states requires substantial setup, and maintaining tests becomes costly, as even small production changes force updates across large parts of the test code. The result is a system that is hard to get right—and once it works, it feels rigid and difficult to evolve.

The testing‑centric view

When we look at the problem from the testing point of view, the issues become clearer.

1. Unit‑testable code – we aim for code structured in smaller parts that can be executed in isolation.
2. Separation of concerns – provides the units for testing.
3. Dependency injection (DI) – to run modules independently, a module’s dependencies are passed in (normally via a constructor argument).

In a unit test where a single module should run in isolation, all dependent modules need to be mocked. Instead of real dependencies, the test passes its mocks as constructor arguments.

First issue: No testing without mocking

• Mocking works technically – unit testing is enabled.
• The price is high: mocks must be written and maintained, increasing test‑specific code and overall test complexity.
• Only if all mocks are implemented correctly does the test remain useful.

Second issue: Interfaces create tight coupling

• Mocks must implement the same interface as the real components they replace.
• Interfaces often contain several inter‑dependent function signatures with non‑trivial pre‑ and post‑conditions.
• Any change to the interface affects all implementations and all mocks, increasing maintenance effort.
• With DI and many mocks, this interface‑level coupling becomes especially visible and expensive.
• We end up trading testability for flexibility – a poor deal.

Third issue: State handling in OOP

• State encapsulated within a class is hard to modify from a test.
• Private mutable state is fully hidden, so tests cannot set it up directly.
• To reach a specific internal configuration, a test must drive the state indirectly through the public interface, often requiring multiple method calls, complex sequences, and mocks.
• This indirect setup adds complexity and makes tests brittle.

Fourth issue: Distributed state

• State is usually cluttered across the object graph, introducing hidden dependencies that are hard to see.
• The more stateful objects exist, the harder it is to reason about how state evolves, compounding the test‑related complexity described above.

Fifth issue: Inheritance‑driven coupling

• Tight coupling of implementations sharing an interface can be described more generally as inheritance creates tight coupling within the hierarchy.
• Once a class hierarchy is established, the base‑class interface becomes almost impossible to change without impacting every derived class.
• The deeper the hierarchy, the worse the problem: even small adjustments propagate through, making hierarchies inflexible and expensive to modify.

Summarising the root cause

All these problems create a lot of complexity, which leads to the pain described at the beginning. The underlying root cause is dependency:

• Components dependent on each other via injection can only be executed in isolation by introducing mocks.
• The broader an interface, the more complex the dependency between components sharing it.
• Inheritance creates dependencies between classes within hierarchies.
• Hidden, distributed, and evolving state creates implicit dependencies across the system.

Every issue we examined boils down to this: dependencies force parts of the system to change together, to be set up together, and to be understood together. As they reinforce each other, complexity grows increasingly fast.

A different way of structuring code

I started questioning the design ideas I had followed for years and searched for alternative ways to manage these dependencies. The blog post Mocking is Code Smell helped me see the problem more clearly and pushed me to explore functional ideas that turned out to be particularly useful.

Put simply, functional programming offers techniques that can complement a traditional C++ toolbox. These techniques work because they change how we design systems—and with that, which dependencies emerge.

What changes with pure functions?

By using pure functions as building blocks:

• Dependencies become explicit – they are passed as arguments rather than hidden inside objects.
• Mocking is reduced – there is little to mock because functions don’t rely on external mutable collaborators.
• State is visible – any state a function needs is supplied directly, eliminating hidden, distributed state.
• Interfaces stay small – function signatures are typically narrower than class interfaces, keeping dependencies simpler.
• No inheritance hierarchy – removing an entire class‑hierarchy coupling problem.

Takeaway

• C++ systems become hard to test and evolve when dependencies accumulate through injection, broad interfaces, inheritance, and hidden mutable state.
• Functional programming techniques—especially pure functions—re‑expose those dependencies, making them explicit, narrow, and immutable.
• By redesigning parts of a C++ codebase around pure functions (or function‑like abstractions such as std::function, lambdas, and value‑semantic types), you can dramatically reduce the need for mocks, simplify state handling, and break the tight coupling that fuels complexity.

Adopting these ideas doesn’t mean abandoning OOP entirely; it means combining the strengths of both paradigms to keep dependencies under control and make your C++ systems easier to test, evolve, and maintain.

# Class of Dependencies

In conclusion, when you compose your business logic out of pure functions, dependencies become **explicit, fewer, and simpler**. This directly mitigates complexity.

> **Note:** I am not claiming that functional programming will solve every problem, nor that it can be applied in C++ without limits. There are, however, aspects that are highly valuable when designing C++ systems. I advocate for **complementing OOP with FP where appropriate**.

Adopting a different way of structuring code takes effort, and how much depends on your learning path. If you’re coming from an OOP‑heavy, C++‑style background like I did, I can speak your language well enough to further clarify these techniques and design choices.

My original motivation wasn’t to write about system design or functional programming. I simply wanted to figure out how to apply these ideas effectively in real‑world C++ code. After exploring this for a while and finding techniques that work, it feels natural to share and discuss them.

The **funkyposts** blog is meant to build a bridge between traditional C++ and functional programming by illustrating practical FP patterns in modern C++. The goal is to provide concrete ways to improve how systems are structured—while staying grounded in real‑world constraints. I also welcome feedback and different perspectives to further refine these ideas.

The next step is to leverage these insights in practice—improving existing designs without rewriting everything. The subsequent posts in this series show how.

Upcoming Posts in the Series

1. Handling Side Effects in Modern C++: Interfacing Pure Functions with Our Imperative World
   Using the functional core–imperative shell pattern to mitigate dependencies.

2. When One Shell Isn’t Enough: Scaling the Functional Core–Imperative Shell Pattern with Actors in C++
   How to structure growing C++ systems into actor‑driven core–shell pairs that isolate dependencies.

More posts in this series coming soon.

About the Blog

Part of the funkyposts blog — bridging object‑oriented and functional thinking in C++.

GitHub Repository – funkyposts (v06)