4 ms·
Totally agree, I would introduce immutability in OO to address Concurrency issues. In short, picking the best of both worlds. Where the conflicts arise is whe
by sidcool 8y ago
Totally agree, I would introduce immutability in OO to address Concurrency issues. In short, picking the best of both worlds.
Where the conflicts arise is when we have stateless functions. It's a bad practice from OO perspective to have stateless (or static) functions. I am yet to have a good solution to this problem.
- gmueckl 8y agoObjects shine when they encapsulate complex state in ways that disallow illegal states to arise. The trouble starts once you try to add complex transformation processes (e.g. business processes) to objects. When they work on complex graphs of objects, you can't really put them into a single one of them as none of them is the obvious place. What I found to work best is to build an OO data model and a (not necessarily functional) business logic layer on top. In pure OO languages like Java and C# this layer takes on singleton characteristics, which is a clear sign that this code should be simply procedural. The individual functions are often not very interdependent and easy to work on and test.