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:La respuesta de Lahman:
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)
> will that not handicap me?Respondiendo a Arnuld
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 CYour 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.
> 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)
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.)
[>>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.Comparando ambos paradigmas, agrega:
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.]
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.Pero Kazakov apunta, y disiente:
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.
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.Esta discusión recién comienza...Como siempre, suele enriquecerse y extenderse.
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.