9 ms·
This is also the reason that most heavy abstractions fail. Abstractions often define the rules for one very specific universe. When the next CEO comes in a dec
by cjonas 4y ago
This is also the reason that most heavy abstractions fail. Abstractions often define the rules for one very specific universe. When the next CEO comes in a decides to toss that universe, it can become almost impossible to reason about our new reality in the context of the old abstractions.
For this reason, I tend to stear away from OOO design patterns in domain logic. I've found that simple function based code written around algebraic data types tends to be much more fluid and able to conform to changing worlds.
Ironically, that as I've gotten more SR, the code I produce tends to be much simpler...
- eru 4y agoYes, object oriented design promised a lot of re-use that never happened (at least not like that). Instead in the real world, re-use happened via libraries. And very much along the lines you sketched.
- DenisM 4y ago> I've found that simple function based code written around algebraic data types tends to be much more fluid and able to conform to changing worlds. How do you explain that?
- cjonas 4y agoBecause the ADT mostly just describe the shape of data moving through the system. Less control flow and logic is tied up in abstraction. Functions are typically small, pure and either "composable" or "disposable"
- BerislavLopac 4y agoLike everything else in software development, there are different valid approaches, and it's up to us (the developers) to use them in ways that suit us the most. I've come to realise that all coding, regardless of the language, comes down to two things: 1. defining what the data we're working on looks like 2. defining what do we want to do with that data Different languages and "paradigms" approach these "things" in different ways: OOP revolves around the idea of the operations and the data being hauled around together, in a single "object"; functional programming strictly separates the two into functions and data types; and so on. In your case, the approach you're describing works great, and fits your use case perfectly; in some other cases, a more object-oriented approach is a better fit. There is no silver bullet.