On Monday, 1 September 2025 at 14:14:58 UTC, Serg Gini wrote:
On Monday, 1 September 2025 at 13:58:23 UTC, Brother Bill wrote:
I have heard that there are better or at least alternative
ways to have encapsulation, polymorphism and inheritance
outside of OOP.
With OOP in D, we have full support for Single Inheritance,
including for Design by Contract (excluding 'old'). D also
supports multiple Interfaces.
What would be the alternatives and why would they be better?
I assume the alternatives would have
1. Better performance
2. Simpler syntax
3. Easier to read, write and maintain
If possible, please provide links to documentation or examples.
Usually alternative is related to composition.
https://en.wikipedia.org/wiki/Object_composition
https://en.wikipedia.org/wiki/Composition_over_inheritance
There are certainly alternative ways to OOP.
But the problem you face, is not so much alternatives to OOP, but
rather, that different worlds collide.
That is, the real world collides with the computational world.
So do you see the problem you're trying to solve as as a
collection of interacting objects? - i.e. things have state,
identity, and behavior (i.e much like we perceive the real world)
If so, OOP does well in modelling that world - where a class type
represents that real-world entity (with state, identity, and
behavior).
This aligns the real world problem your trying to solve with the
code structure, so that the code structure itself provides
clarity around the problem you are trying to solve.
But, the code itself operates in a world of its own - separate
from the object-like world that we perceive.
That is, code operates in the computational world - which is
governed by the rules of performance - which is related to the
CPU, memory cache, compilers, garbage collection ... etc.
So any alternatives to OOP will likely be more focused on
optimizing for the computational world, and less focused on
modelling the real world, as we perceive it.
Then, instead of modelling what things are (i.e. things with
state, identity, and behavior) you'll likely be modeling
something different.
So, it's all about the collision of two different worlds - the
real world as we percieve it, and the computational world.
'Better performance' is a good reason to model it differently to
the real world.
'Simpler syntax' is a good reason to model it differently to the
real world.
'Easier to read, write and maintain' is also a good reason to
model it differently to the real world.
And, 'the problem domain being in the computational world rather
than the real world' is also a good reason to model if
differently.
I'm sure there are other good reason as well.
So, yes. There are certainly reasons for choosing alternative
ways to OOP, but they will likely be more focused on the
computational world, than the real world as we pereive it.
