Non-pipeline component programming

[Paulo Pinto via Digitalmars-d]

On Thursday, 4 September 2014 at 10:12:13 UTC, Chris wrote:
> On Wednesday, 12 February 2014 at 17:38:30 UTC, H. S. Teoh 
> wrote:
>
>>
>> I would say that while it's insightful to apply different 
>> paradigms to
>> solve the same problem, one shouldn't make the mistake of 
>> shoehorning
>> *everything* into the same approach. This is what Java does 
>> with OO, for
>> example, to the detriment of every other paradigm, and 
>> frankly, after a
>> while all those singleton classes with static methods just 
>> start to
>> smell more and more like ways of working around the OO rather 
>> than with
>> it.
>
> I found myself using singelton classes more and more until I 
> decided it was time to drop a strict OO approach.

In Smalltalk and Eiffel, where everything is an object this tends 
not to
be a problem, because they lack modules anyway.

So objects with class methods play the role of modules in a way 
that doesn't feel so strange like in Java and C#. Which given its 
package support, it would be more natural to associate certain 
code with the package, not with objects.

C# extension methods feel funny because of their requirement to 
be encapsulated into a (dummy) class, for example.

>
>> Having said that, though, the component approach is highly 
>> applicable,
>> often in unexpected areas and unexpected ways, esp. when you 
>> couple it
>> with D's range-based concept. There are certainly algorithms 
>> where it
>> makes more sense to treat your data as a graph rather than a 
>> linear
>> sequence of nodes, but it's also true that a good percentage 
>> of all code
>> is just variations on linear processing, so pipelined 
>> component-style
>> programming would definitely be applicable in many places.
>>
>> And nothing says you can't intermix component-style code with 
>> OO, or
>> something else.
>
> That's what I've been doing for the last 1 1/2 years. I use 
> classes where it makes _sense_, not as the ruling paradigm, 
> then add structs (components), ranges and templates. The good 
> thing about the freedom D offers is that it encourages you to 
> think about the fundamental logic of your program and use 
> tailor made solutions for a given problem - instead of a one 
> size fits all approach that is bound to lead you down a cul de 
> sac. In a way D has given the power back to the programmer's 
> brain.

This was actually my first issue when I learned OO in Turbo 
Pascal 5.5,
my first OO language.

It was a learning process to understand what should become an 
object, and
what should stay as usual procedural (functions/records/units) 
code.


Regarding component programming in general, this used to be a 
good book on the subject. Only read the first edition (based in 
Component Pascal), the second was updated to more "modern" 
languages.

http://www.amazon.com/Component-Software-Object-Oriented-Programming-Addison-Wesley/dp/032175302X

--
Paulo