There are two styles of object-oriented programming: domain-oriented and pattern-oriented. Both have their place. Practical OO is about resolving the tension between them.
Domain-oriented OO leads us to code beautiful unique snowflakes. Sometimes this is great! Sometimes... no.
Domain-oriented OO leads us to code beautiful unique snowflakes. Sometimes this is great! Sometimes... no.
Pattern-oriented OO: Models, Views, Controllers. Presenters. Workflows. Delegators. Facades. Query Objects. All code has a box; find the right one.
Domain-oriented OO: What are the nouns in this business problem space? What are the verbs?
Domain-oriented OO: What are the nouns in this business problem space? What are the verbs?
Domain-oriented OO requires developers to be precise about saying what they mean. It's fragile against shortcuts and handwaving. Failure modes include god classes & "idiosyncratic" object decomposition. These are real failure modes!
Pattern-oriented OO has different failure modes. It can lead to arbitrary-feeling "layer cake" architectures. These can be hard to onboard onto -- each team defines "presenter" or "workflow" slightly differently in practice, and this can't be shortcut through w/ domain knowledge.
Pattern-oriented OO is great for shops that work on many products (like agencies) or shops that are expanding rapidly and hiring folks with homogenous backgrounds (who can be expected to more or less know a given pattern-set).
It's less good for products small teams own.
It's less good for products small teams own.
Domain-oriented OO can have significant upfront costs, because it *cannot* be done without getting stakeholders and developers aligned on the same model of the world. It requires developers to use sharp knives, and sometimes those sharp knives cut.
It pays off in the long term.
It pays off in the long term.
Domain-oriented OO makes it easier to build *operable* systems. It makes it easier to introspect what's going on in a running system, and to make small extensions. Later features are easier, and support engineering doesn't need to throw their hands up in despair.
But the fact that domain-oriented OO builds you more operable systems *when it's done well* does not protect one from the fact that it's nightmarish when done badly. How do we reconcile the gains domain thinking gives us & the support that "layer cake" architectures can give us?
