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.
