2 ms·

To be fair, that was also the major point of OO, and of structured programming before that.

• chrischen 6y ago
  Could you elaborate?
  • gmfawcett 6y ago
    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 principle? A paradigm where making big things from small things is actually an anti-pattern?
    • 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.