Non-pipeline component programming

["Luís]

I loved reading Walter's component programming article in Dr. 
Dobb's [0] in late 2012. I had missed H. S. Teoh's mid 2013 
article on calendar textual formatting using the component 
approach [1], but fortunately Ali brought it to my attention 
recently, and I also find it absolutely fascinating!

I think what's most interesting with Teoh's article (and I think 
that was Ali's point when he mentioned the article to me) is that 
the calendar example is not as an obvious target for the 
component approach, or at least that the design and 
implementation is not as obvious for someone new to that approach.

Now, while Teoh's example is much more complex than Walter's, 
both examples are for cases of pipelined problems (source -> 
filter1 -> filter2 -> sink). What I have been wondering during 
the last few days is how much this "component programming" 
approach could be applied to scenarios where you would normally 
have a jumble of objects. For instance, try to picture a game or 
simulation where spaceships fire at each other, pick up objects, 
communicate, and so on, or something like that. My instinct would 
be to code a solution which would be classified as typical OOP 
code. Would it be possible to come up with a solution that would 
be more in the spirit of "component programming"? Or are such 
solutions only practical/applicable for pipeline-like scenarios?

--

[0] 
http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321

[1] 
http://wiki.dlang.org/User:Quickfur/Component_programming_with_ranges