Functional patterns that replace classes

In a language where functions are values, several class-based patterns shrink to a function. A Strategy becomes a function passed as an argument, a Command becomes a function or a closure stored for later, and a Template Method becomes a function that takes its varying steps as parameters. Peter Norvig counted this in 1996: 16 of the 23 classic patterns had simpler forms in Lisp or Dylan, and first-class functions alone accounted for four of them, Command, Strategy, Template Method and Visitor. The same thinking gives three more tools: closures and partial application to configure behaviour, errors returned as values instead of thrown, and a design that keeps decisions in pure functions and input and output at the edges. Keep a class when the varying part holds state, has several operations or deserves a name in the domain.

A Strategy as a function

Each pattern has a functional form, and the idea behind it stays the same:

• Strategy: an interface and one class per algorithm become a function passed as an argument, or a table of functions.
• Command: an object with an execute() method becomes a function or a closure, stored and called later.
• Template Method: a base class whose steps subclasses override becomes a function that takes its varying steps as parameters.

Settings follow the same move. A class whose constructor stores a threshold or a percentage becomes a closure that captures it, or a general function with that argument fixed by partial application, so there is no class left to name, construct or keep in step with an interface.

The four ideas that the rest of this lesson builds on, each in one sentence:

• Higher-order functions take or return functions, which is all a Strategy or a Command needs.
• Partial application fixes some of a function’s arguments now and returns a function that takes the rest.
• Errors as values means returning a result that is either a value or an error, so the caller must look at it.
• Functional core, imperative shell keeps the decisions in pure functions and pushes input and output to a thin outer layer.

Here two shipping rules are written both ways. The class version needs an abstract base and a class per rule; the function version is two functions, a dictionary of them, and functools.partial to fix the threshold of one:

"""Strategy without classes. The class version needs an interface and one class per rule; with first-class
functions, a rule is just a function, a table of rules is a dictionary, and functools.partial turns a general rule
into a configured one. Amounts are whole paise, so no rounding surprises."""

from abc import ABC, abstractmethod
from functools import partial


# ---- the class-based Strategy -------------------------------------------------------------------------------------
class ShippingRule(ABC):
    @abstractmethod
    def fee(self, order_paise: int) -> int: ...


class Flat(ShippingRule):
    def fee(self, order_paise):
        return 4_000


class FreeAbove(ShippingRule):
    def __init__(self, threshold_paise):
        self.threshold_paise = threshold_paise

    def fee(self, order_paise):
        return 0 if order_paise >= self.threshold_paise else 4_000


# ---- the same rules as functions ------------------------------------------------------------------------------------
def flat(order_paise):
    return 4_000


def free_above(threshold_paise, order_paise):
    return 0 if order_paise >= threshold_paise else 4_000


RULES = {"flat": flat, "free above 499": partial(free_above, 49_900)}  # partial fixes the first argument

for order in (29_900, 49_900, 120_000):
    by_class = [Flat().fee(order), FreeAbove(49_900).fee(order)]
    by_function = [RULES["flat"](order), RULES["free above 499"](order)]
    print(f"order {order} paise: classes {by_class}, functions {by_function}, same: {by_class == by_function}")
print("classes needed for two rules:", len(ShippingRule.__subclasses__()) + 1, "| functions needed:", 2)

order 29900 paise: classes [4000, 4000], functions [4000, 4000], same: True
order 49900 paise: classes [4000, 0], functions [4000, 0], same: True
order 120000 paise: classes [4000, 0], functions [4000, 0], same: True
classes needed for two rules: 3 | functions needed: 2

Both versions agree on all three orders. The function version has no interface to keep in step and no class to name, and adding a rule is adding a function to the dictionary. What it gives up is the place to put more than one operation or any state of the rule’s own, which is exactly when the class form earns its keep.

A pricing engine: four classes, then four composed functions Pro: opens with a Pro, Premium or Ultimate pass