Alternatives to OOP in D

[Peter C]

On Monday, 1 September 2025 at 15:59:24 UTC, monkyyy 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.
>
>
>> claims to not start flame wars
>
> Its the wrong question you should answer 3 questions:
>
> 1. where is the data
> 2. how does data mutate
> 3. how do I control flow
>
> oo is bad because its answers all three questions as **a 
> noun**; "Im just going to vistor pattern my gamestate manager 
> with my mailboxes"
>
> to *start with* Id suggest 2 different styles:
>
> 1. going full ranges(standard)
>
> This is a mostly functional style, theres nothing enforcing you 
> to be pure, but first class functions is just how `.map` works. 
> "Ranges are views of data", so the data stays where it started, 
> if you start with a File(...).byLineCopy, the data is in the 
> file, same with a json parser that provides a range interface. 
> You mutate data with maps and reduces, and you manage control 
> flow with take, drop and sort
>
> 2. plain old c
>
> You have global scope, malloc and goto. You can at any time 
> make all your data in global scope write a giant function; if 
> you must allocate, call malloc, you just go edit data directly 
> and you can do any control flow with goto as its the only thing 
> hardward can do.
>
> The answers the the 3 questions are mix and matchable.
>
> ---
>
> Polymorphoism isn't remotely owned by oo, templates are more 
> polymorphic, usually "upgrades" to templates like "generics" 
> are about **preventing** their full polymorphic; contracts, 
> generics, all this talk about function attributes, all of it is 
> trading off the flexibility of templates to chase some safety.


*If* the problem domain is in the real world, and not the 
computational world, then your proposed Data-Oriented Design 
(DOD), which intentionally breaks an entity apart into its 
constituent data components, effectively destroys the natural, 
cohesive identity we assign to real-world objects, making 
high-level reasoning more fragmented.

When I'm in a meeting with customers, I'm discussing "Customers," 
"Orders," and "Invoices" (OOP concepts), which is far more 
natural and clearer than discussing "data streams".

The model that best facilitates human thought, design clarity, 
and communication in the real world, is the Object-Oriented 
model. It is clearly the most effective model for describing the 
world.

So why would I break an OO view of the world into a DOD view of 
the world?

Well...to better fit the computational world.

Of course then you are trading off design clarity for execution 
performance.

My point: Neither OOP nor DOD is bad.

In an encapsulated model, you have strong cohesion refecting a 
real-world entity.

In an data-oriented model (where the goal is to process data as 
efficiently as possible) data is separated from behaviour, and 
behaviour acts upon these separated data sets, in order to 
prioritise computational efficiency over real-world object 
cohesion.

Rather than calling methods on individual objects one at a time 
(which can have a computational disadvantage - e.g. a a cache 
miss), the CPU is can be fed a smooth, continuous stream of work.

So while DOD excels at computational efficiency, it introduces a 
significant cognitive trade-off for the programmer, by shifting 
from an Object-Oriented (OO) view to a Data-Oriented Design (DOD).

This can make the code harder to read and reason about.