Flow-Design: OOP component programming

[Luís Marques]

It seems that someone once again rediscovered the benefits of 
component programming, in the context of OOP, but (as usual) 
without the more mathematical and principled approach of 
something like ranges and algorithms:

<http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/flow-design-cheat-sheet-ndash-part-i-notation.aspx>

"The purpose of FUs is to process input and produce output. FUs 
are transformational. However, FUs are not called and do not call 
other FUs. There is no dependency between FUs. Data just flows 
into a FU (input) and out of it (output). From where and where to 
is of no concern to a FU. This way FUs can be concatenated in 
arbitrary ways: (...) Each FU can accept input from many sources 
and produce output for many sinks: (...) Connected FUs form a 
flow with a start and an end. Data is entering a flow at a 
source, and it´s leaving it through a sink. (...) You could say, 
Flow-Orientation is about tackling complexity at its root cause: 
that´s dependencies. “Natural” dependencies are depicted 
naturally, i.e. implicitly. And whereever possible dependencies 
are not even created. Functional units don´t know their 
collaborators within a flow. This is core to Flow-Orientation. 
That makes for high composability of functional units."

BTW, I just wrote my DConf proposal. I've been experimenting with 
a different style of not-quite-OOP in a real project and so far 
I'm really happy with the results. I've been making use of 
Jean-Louis' openmethods.d library, as well as other D features 
and techniques. The result is a quite nice balance of simplicity, 
expressiveness and performance. I'm really looking forward to 
telling you all about it :-)