Why Are Reusable Components So Hard? A FP vs OO FizzBuzz Experiment

Several weeks ago Uwe Friedrichsen raised the question of why component reusability is so difficult in a blog post, citing examples such as CORBA, component‑based architectures, EJB, and SOA, and asking whether micro‑services would change the outcome.

…Reusability is the trump card of software: whenever a new architectural paradigm appears, reusability becomes a core consideration for its adoption. Yet the promised benefits of reusability rarely materialize.

The author argues that the difficulty stems from differing assumptions in classic object‑oriented programming (OO) and pure functional programming (FP). To illustrate, a FizzBuzz implementation is written in both F# (FP) and C# (OO).

F# implementation (FP)

let (|DivisibleBy|_|) by n = if n%by=0 then Some DivisibleBy else None
let findMatch = function
  | DivisibleBy 3 & DivisibleBy 5 -> "FizzBuzz"
  | DivisibleBy 3 -> "Fizz"
  | DivisibleBy 5 -> "Buzz"
  | _ -> ""
[<EntryPoint>]
let main argv =
    [1..100] |> Seq.map findMatch |> Seq.iteri (printfn "%i %s")
    0 // we're good. Return 0 to indicate success back to OS

Three observations about the F# code:

The code is highly fragmented; the pieces appear unrelated at first glance.

Adding a new rule is as simple as extending the DivisibleBy pattern.

The final part of the program is minimal and can be written in many ways, allowing the programmer to choose the most cognitively light solution.

An alternative, more compact version:

let fizzBuzz n = n |> Seq.map findMatch |> Seq.iteri (printfn "%i %s")
fizzBuzz [1..100]

This version treats the whole process as a single node that can be easily reused with different input ranges.

C# implementation (OO)

// from https://stackoverflow.com/questions/11764539/writing-fizzbuzz
namespace oop {
    class Program {
        static void DoFizzBuzz1() {
            for (int i = 1; i <= 100; i++) {
                bool fizz = i % 3 == 0;
                bool buzz = i % 5 == 0;
                if (fizz && buzz)
                    Console.WriteLine(i.ToString() + " FizzBuzz");
                else if (fizz)
                    Console.WriteLine(i.ToString() + " Fizz");
                else if (buzz)
                    Console.WriteLine(i.ToString() + " Buzz");
                else
                    Console.WriteLine(i);
            }
        }
        static void Main(string[] args) {
            Console.WriteLine("Hello World!");
            DoFizzBuzz1();
        }
    }
}

The C# version is roughly three times longer than the F# version, and several points stand out:

The structure is fixed: a namespace, a class, and a method, each with a specific purpose.

Adding a new rule requires inserting additional boolean checks and extending the nested if/else chain, increasing complexity.

While C# offers strong encapsulation through namespaces and classes, this rigidity can hinder component reuse when the code is tightly coupled to the Main method and specific ranges.

In OO code, everything has a designated place, and design rules (such as SOLID) often dictate the structure before the actual behavior is known. In FP, the focus is on minimal cognitive load and composable primitives, allowing the same logic to be expressed with far fewer lines.

The article concludes that neither paradigm is inherently superior for reuse; OO provides a clear, hierarchical organization that can become cumbersome when extending functionality, whereas FP yields highly reusable, low‑coupling components but may lack the guiding design principles that OO enforces.

Original source: https://danielbmarkham.com/why-are-reusable-components-so-difficult/