Component programming

[Jason den Dulk]

On Wednesday, 31 July 2013 at 10:20:57 UTC, Chris wrote:
> This is only losely related to D, but I don't fully understand 
> the separation of component programming and OOP

What the wikipedia entry is saying, in a roundabout way is:

All objects are components, but not all components are objects.

whereas in pure OOP:

All components are objects.

> In an OO framwork, the objects are basically components.

It's the other way around. In OOP frameworks, components are 
objects, a small but important distinction. If you relax the 
insistance on all components being objects, then OOP becomes a 
subset of CP (component programming).

> Walter's example 
> (http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321)
>
> void main() {
>         stdin.byLine(KeepTerminator.yes)    // 1
>         map!(a => a.idup).                  // 2
>         array.                              // 3
>         sort.                               // 4
>         copy(                               // 5
>             stdout.lockingTextWriter());    // 6
>     }

This is a design pattern called "pipes and filters", or simply, 
the pipeline. There appears to be a bit of confusion about this. 
Pipelines are a part of CP, but is not the whole of CP.

Pipelines make use of a type of component called a "service". At 
its simplest, a service is a function, but it could be a larger 
construct or even a whole program. Basically a service takes 
input, processes it (with a possible side effect) and gives a 
response (output).

Often CP is defined as being exclusively about services, while 
other definitions include objects and OOP. Functional programming 
is exclusively service oriented.

Purists would insist on using either objects or services 
exclusively (OOP vs FP), but there is nothing wrong with working 
with both.

Back to pipelines. In a pipeline, you have a chain of services in 
which the output of one service is given as the input for the 
next. In mathematics it is called "functional composition". The 
pipeline itself is a service in its own right. You can put 
together a pipeline of any length as long as the output -> input 
interfaces are compatible. In Walter's article, he goes further 
to make all interfaces the same to make the components 
interchangeable, but this is not necessary in general.

Hope this helps to explain a few things.
Regards
Jason