Alternatives to OOP in D

[Peter C]

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.