3 ms·

I'll go one further. Can you think of a single programming paradigm in which "composition of small things to make bigger things" isn't a fundamental design prin

• chrischen 6y ago
  Well if I were doing object oriented modeling I may have a `class Person` and some methods that operate on some Person data specific to my model. For example, I may model the person with name, age, job, and gender as a boolean... but in 2020 I may have to then reimplement the gender field entirely. If I later decide to have a `class Pet` it may share some common fields except for the "job" field. Having done this I may now do the opposite of composition in that I'm now factoring out the common properties of a Person and Pet and breaking them into smaller components rather than assembling them from smaller components. If I were doing this functionally and strictly typed I'd have started out with the leaf types of age, job, and gender that were agnostic to their owners (Person or Pet). They'd be implemented in pure way without dependencies or knowledge of a Person or Pet, can be tested and developed before any part of Person or Pet are implemented. Yes you could also compose classes, which are bundles of functions... but if you take that to the next level you'd get function composition. It's not that you can't do composable software with OOP... it's rather that functional programming is all about composition.