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
