applying-solid-functionallylisted

# Applying SOLID Functionally ## Overview The SOLID principles are about the direction and shape of dependencies, not about classes. Every one of them survives translation into functions and data, and in functional code most of them get simpler: the abstraction that other principles reach for with interfaces and inheritance is, here, just a function type. ## When to use - Deciding what a function should take as parameters - Adding a new variant, and finding many places to edit - Two features that change for different reasons live in one module - A module receives a large record of functions and uses two of them - Choosing between a choice type and a passed-in function Not for: naming, or judging interface size in isolation. ## The five, restated | Principle | Functional statement | | --------- | ------------------------------------------------------- | | SRP | One function, one reason to change, one audience | | OCP | Extend by adding code, not by editing existing code | | LSP | Any value of a type honours the type's whole contract | | ISP | Depend on the narrowest function type that works | | DIP | Concrete code depends on function types, not vice versa | ## Core rules 1. **Split by who asks for the change, not by what the code does.** Two calculations that look alike but answer to different stakeholders belong in different modules, whatever the duplication. 2. **Choose the ax