Puedo aprender OOD sin pasar por el diseño procedural?...

Una vez más, el grupo comp.object de Google Groups desarrolla un punto de interés sobre el diseño orientado a objetos (OOD en su sigla inglesa). Un forista indú, Pandit, nuevo en el aprendizaje del diseño de software, pregunta si es necesario pasar por un enfoque "procedural" antes de abordar la visión orientada a objetos. Esta es una pregunta que he visto repetida en otras discusiones, e incluso vi sostenida como currícula de distintas carreras informáticas.
Sigue la pregunta, y dos o tres afirmaciones en contra de este criterio, en palabras de H.S. Lahman, Arnuld, y Dmitri A. Kazakov.
La pregunta de Pandit:

I need to learn OOA-D 1st. so the question now is:
Can i learn OOA-D without learning Proecdural/Modular design 1st?
will that not handicap me?
( i am interested in C++, OOD & Templates and i do not want to learn C 1st, which is procedural. one of my friends, advised me to learn OOD 1st & then C++ but he has no idea on whether to learn procedural or modular 1st as a solid-base of programming or OOD)

La respuesta de Lahman:

> will that not handicap me?

It will not handicap you. In fact, it is a distinct advantage. The OO paradigm is fundamentally different than the traditional procedural approaches. One cannot mix & match the two. A major problem that procedural developers have when they convert to the OO paradigm is that they essentially need to forget everything they learned about proceduraldevelopment.

> ( i am interested in C++, OOD & Templates and i do not want to learn C
> 1st, which is procedural. one of my friends, advised me to learn OOD
> 1st & then C++ but he has no idea on whether to learn procedural or
> modular 1st as a solid-base of programming or OOD)

Your friend is correct. All of the OOPLs are 3GLs so they make substantial compromises with the hardware computational models for things like procedural block structuring, stack-based scope, and procedural message passing. (That is especially true for C++.) As a result it is very tempting to overlay procedural thinking on the OOPLs because syntactically they are procedural languages with added abstract constructs on top.
In addition, the procedural approaches are much more intuitive for algorithmic processing on computers because they grew up in academia solving scientific problems. The OO paradigm works from the opposite end of the spectrum by abstracting customer problem spaces rather than hardware computational models. So it is not very intuitive if one has already learned procedural development.
So get a good OOA/D book and learn the fundamentals of the OO paradigm first. (The Books category of my blog has some guidelines for selecting a good book.)

Respondiendo a Arnuld
[>>In addition, the procedural approaches are much more intuitive for
>>algorithmic processing on computers because they grew up in academia
>>solving scientific problems. The OO paradigm works from the opposite end
>>of the spectrum by abstracting customer problem spaces rather than
>>hardware computational models. So it is not very intuitive if one has
>>already learned procedural development.
> Lahman, doesn't that mean: "a programmer will learn more about
> programming from algorithms and procedural approach rather than from
> OOD" ]
, Lahman dice:

Not quite. What it means is that OO development requires a different mental approach to problem solving that procedural development. My point here is that there is a substantial learning curve in adopting OO techniques, more than for applying procedural techniques in a computing environment. That's because the OO paradigm is focused on problem space abstraction rather than hardware computational models. Most customer problem spaces are not highly algorithmic.
For example, IT is characterized by applying lots of quite trivial individual algorithms to mountains of data. In a General Ledger application a heavy duty algorithm is a long division in an allocation.
The real problems lie in managing the data and organizing a gazillion small algorithms that need to be cobbled together in complex ways.
(That's why it was called Data Processing for two decades before Information Technology became fashionable.)
Corollary: if you need to solve an atmospheric diffusion problem, the OO paradigm is probably not the way to do that. B-) One doesn't use OO techniques to implement a Quicksort algorithm even if one can identify objects like Pivot and Partition. That's because the goal of the OO paradigm is maintainability in the face of volatile requirements over time. The Quicksort algorithm isn't going to change over time so one gets no benefit for using OO techniques while procedural techniques are quite intuitive for the problem.
[OTOH, OO techniques are good for gluing together different algorithms and dealing with the peripheral stuff like organizing data, UIs, and persistence. So even complex algorithmic problems can benefit from using OO techniques at the next level up from the pure mathematical algorithms. IOW, use the right tool for the problem.]

Comparando ambos paradigmas, agrega:

The paradigms are almost diametrically opposed. Procedural techniques are based on functional decomposition with its hierarchical dependencies. One can argue that the whole point of the OO paradigm is to eliminate hierarchical dependency structures.
All that good OO stuff -- encapsulation, separation of message and method, decoupling, implementation hiding, flexible logical indivisibility, problem space abstraction of intrinsic properties, capturing business rules in static structure, etc., etc. -- plays together expressly to eliminate hierarchical dependencies.

Pero Kazakov apunta, y disiente:

In some sense yes it definitely is. Methods are procedures. Their decomposition is procedural. However some types of decomposition are automated (upon inheritance or delegation). Further, for meta programming, OOPLs provide new types of procedures to deal with classes.
There is no way to get rid of this sort of decomposition when the number of states is any large. What any procedure does is in fact an abstraction of a set of state transitions. You describe a bunch of transitions like 1->2, 2->3, 3->4, etc by a function inc:N->N. The difference is like between finger counting and arithmetic. Now what OO does (on this basis) is identifying N, the set of natural numbers for which arithmetic works.

Esta discusión recién comienza...Como siempre, suele enriquecerse y extenderse.