Why Reusable Code Eludes Us: FP vs OO Through a FizzBuzz Experiment

Why Reusable Code Remains Elusive

Uwe Friedrichsen argued that promises of code reusability across paradigms (CORBA, component‑based, EJB, SOA, microservices) often fail to materialise.

Experiment: FizzBuzz in F# (Functional Programming)

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 // return 0 to indicate success

Key observations:

The code is highly modular; new rules can be added by extending the DivisibleBy pattern without touching other parts.

The final processing step is expressed as a pipeline, allowing any downstream operation (printing, collecting, further transformation).

All logic resides in the global namespace, so changing the numeric range or output format requires no structural changes.

A more compact formulation groups the pipeline into a single function:

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

Calling the function with a different range demonstrates reuse:

fizzBuzz [50..200]

Experiment: FizzBuzz in C# (Object‑Oriented Programming)

// from https://stackoverflow.com/questions/11764539/writing-fizzbuzznamespace
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();
        }
    }
}

Key observations:

The structure is fixed (namespace, class, static methods); this order provides discipline but tightly couples components.

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

The static Main method couples the entry point, range, and output logic, limiting flexibility for reuse.

Comparative Insights

Both paradigms can produce reusable components, but they differ in how reuse is achieved.

Functional programming treats code as composable nodes that can be rearranged with minimal friction; extending behaviour is done by adding new pattern matches.

Object‑oriented programming relies on encapsulation and explicit hierarchies; while it yields well‑structured components, it often introduces tighter coupling between behaviour and its container.

When targeting micro‑services or containerised deployments, the FP version can be repurposed with little modification, whereas the OO version may require substantial refactoring to decouple the Main method from business logic.

FP excels at creating lightweight, easily extensible logic; OO provides a disciplined framework for large‑scale applications. Understanding these trade‑offs helps engineers choose the appropriate approach for the desired level of reusability.