Component based programming in D

[Ola Fosheim Grøstad]

On Tuesday, 18 June 2019 at 09:17:09 UTC, Bart wrote:
> I'm new to component based programming. I've read it is an 
> alternative to oop for speed.

Component based modelling is part of the OO-modelling toolbox.  
Also, it isn't new, e.g. database-oriented modelling techniques 
often use the same philosophy (e.g. SA-modelling and ER-modelling 
predates object-oriented-modelling).

It isn't about speed, it is about being able to combine 
independently written frameworks (or components) using an id as 
an identifier for an entity. It also helps when your 
implementation spans over many computers (or services).

So basically, if you have an independently written 
hotel-reservation component, a golf-course component, a flight 
ticket component and so on, then you can compose this to a full 
"vacation system" by combining the various components.

Nothing new about this, but it got traction around 15-25 years 
ago as software got expensive to build from scratch (as programs 
grew larger) and you want to develop a framework of prewritten 
components that can be combined for easier and cheaper production.

So in that respect you probably, in most cases, trade performance 
(slower) for easy reuse and easier debugging (in some cases).

In the game community they claim to do it for performance 
reasons, but that is probably not the case, it is again about 
costs of doing multithreaded programming and splitting the 
codebase into specialized chunks that different teams can work on 
for good performance on individual parts.

So yeah, the claim is "speed", but there is no real substance to 
that claim, in the general case. Speed isn't a result of the 
generic modelling-strategy. But in some scenarios it might be 
easier to partition the design into components and make each 
component perform well than doing it as a monolithic design.

Although in theory the monolithic design should always perform 
better if done in an optimal fashion. The problem is that it is 
too expensive to do an optimal monolithic multi-threaded design 
well (and change becomes difficult).

E.g. the most high performing OS-kernels are monolithic for 
performance reasons. However, the development costs of that 
approach are prohibitive for ordinary software (even games).


> Can someone help me understand this a little better and how I'd 
> go about using it in D? Specifically I'm looking at the pros 
> and cons, what are the real similarities and differences to 
> oop, and how one implements them in D(taking in to account D's 
> capabilities).


It has precious little to do with the programming language. It 
has more to do with modelling. So you probably will learn more 
from looking at component based modelling as a tool in your 
OO-modelling toolbox than following a particular implementation 
of a component based design.

Unless you want to write games, in which case you should look in 
that direction. (e.g. reuse an existing physics component).

Ola.