can i learn OOD without any procedural 1st

hai,

this is my very 1st post here. i don't know anything expect some Lisp,
one of my friends taught me Lisp.

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)

thanks

-- pandit

On Feb 20, 11:44 am, "pandit" <jala...{}> wrote:
> hai,
>
> this is my very 1st post here. i don't know anything expect some Lisp,
> one of my friends taught me Lisp.
>
> 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)
>
> thanks


you can read my post titled "struggling with design-paradigms".

BTW, i have also discussed the same with someone on my email. if you
want, i can send you the relevant email-communication.

> you can read my post titled "struggling with design-paradigms".


yes, i read that one but it is ambiguous.

> BTW, i have also discussed the same with someone on my email. if you
> want, i can send you the relevant email-communication.

sure, if you can.

Responding to Pandit...

> this is my very 1st post here. i don't know anything expect some Lisp,
> one of my friends taught me Lisp.
>
> 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?

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 procedural
development.

> ( 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.)


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl{}pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info{}pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

> 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"

?


> 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.)

personally, i found OOSC by Bertrand Meyer better. you agree here with
me, Lahman

;-)

thanks

just changed the subject, to make it more clear

Responding to 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"
>
> ?

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.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl{}pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info{}pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

Responding to Arnuld...

> just changed the subject, to make it more clear

I have to strongly disagree. 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.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl{}pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info{}pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

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.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Feb 21, 8:38 am, "H. S. Lahman" <h.lah...{}verizon.net> wrote:
> Responding to 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"
>
> > ?
>
> 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.

I have to intervene here. This is highly unproven, at least for the
business domain. Subroutines and SQL queries are hardly "hardware
compuational 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.

They used to sell it primarily for "reuse". But they change the
alleged benefits/goal every decade as people realize the claims are
unproven or subjective. The OO claim is now shifting from "reducing
maintenance" to "reducing maintenance for large teams". I'd bet money
that next decade it will be different as the large team claim proves
elusive to reality. (OO makes you *need* large teams because it so
verbose in practice now.)

> 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.]
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman

-T-
oop.ismad.com