Booch's book feels too philosophical rather than practical?

hai all,

1st of all i am newbie to what you call OOA-D. so i searched the
archives of this newsgroup & i got this path:

OOA-D -> UML -> OOP

i also noticed one very interesting thing here about OOP step: OOP
should be done preferably in a language that you will not use
professionally, as told by "Lahman". i think he is right.

reagarding OOA-D i see 4-5 recommendations but only 2 are available in
my country: Booch & Rumbaugh

i read some part of chapter 3 of "OOA & D with applications " by Grady
Booch (around 10-12 pages). it feels *too* philsophical rather than
practical, as if he is the king of "academic education" & doing Ph. D
research on OOA-D or something like that. i dont even understand 10% of
what Booch was talking about. it literaly swept above my head :-( . as
per my experience, having a computer degree at hand ( i have a graduate
degree) & writing code professionally are 2 very-very *different*
things & Booch belong to the former side, at least this is is what i
have felt.

Does Rumbaugh writes in the same manner?

UML authors like: Fowler, Page-Jones,Larman are easily available in my
country (INDIA)

i am learning C++ & not able to understand the OOP animal there. i only
have done some non-professional Lisp Programming, like writing some
trivial programmes & dont know any other language. what i want to say
is, functional/procedural style comes naturally to me, this is exactly
how i write trivial programmes & when i faced C++, i was completely
blown-up into pieces. i dont even understand what exactly OOP is.

i want to learn OOP and i dont want to read philosophical concepts. so
i was thinking of buying Craig Larman's "Applying UML and Patterns".
does anybody has any suggestions?


"arnuld"
--
http://arnuld.blogspot.com/
Linux registered user #439610 :: http://counter.li.org/

"arnuld" <arnuld3{}> wrote:

> i want to learn OOP and i dont want to read philosophical concepts.
> so i was thinking of buying Craig Larman's "Applying UML and
> Patterns". does anybody has any suggestions?

I suggest you read Booch as if it was a novel. Don't try to understand
or absorb it. Then read "Designing Object-Oriented C++ Applications
using the Booch Method" by Martin and "Object-Oriented Design
Heuristics" by Riel. These two books really opened my eyes. Then read
Booch's book again and see what you think.

A couple of other book suggestions, not strictly OO: "The Pragmatic
Programmer" by Hunt & Thomas" and "Refactoring: Improving the Design of
Existing Code" by Fowler.

> what i want to say is, functional/procedural style comes naturally
> to me, this is exactly how i write trivial programmes

This is right and natural. OO is a method for handling complexity, it is
rather forced to try to use it in trivial applications.

Read the post below as well:

http://groups.google.com/group/comp....e_thread/threa
d/d6e77220da9d415c/2d3fa888f4ec1652?tvc=2&q=group%3A*software.pattern s*+a
uthor%3Adaniel#2d3fa888f4ec1652

You don't have to intuit OO in order to take advantage of it:

In procedural code, we are taught to move duplicated blocks of code into
a function. Those for whom procedural is "intuitive" are special in that
they can spot duplication before it's in the code and create that
function up front.

People who intuit OO can spot duplicated decision code before typing it.
However, like the beginner procedural person, you don't have to "get it"
in order to take advantage of it after the fact.

When you see two switch statements that both switch off of the same
variable, or two if statements that both check the same condition, just
knock yourself on the head for not catching it beforehand and create
polymorphic classes to remove the duplicated decision code.

On 2007-01-20 03:29:47 -0600, "arnuld" <arnuld3{}> said:

> i want to learn OOP and i dont want to read philosophical concepts. so
> i was thinking of buying Craig Larman's "Applying UML and Patterns".
> does anybody has any suggestions?

Larman's book is quite good. You might also want to read the following
article:

http://www.objectmentor.com/resource...d_Patterns.pdf

Then go and read about each of the principles in turn by finding the
coresponding articles at:

http://www.objectmentor.com/resource...dArticles.html

C++ is a complex language. Learning OOP by learning C++ is a bit like
learning to sing by starting with opera. A simpler language would be
more appropriate. I suggest two:

Learn Ruby to experience what a good dynamically typed OO Language is like.

Then learn Java to see what a relatively simple statically typed OO
language is like.

Then go back to C++.




--
Robert C. Martin (Uncle Bob)**| email: unclebob{}objectmentor.com
Object Mentor Inc.* * * * * **| blog:**www.butunclebob.com
The Agile Transition Experts**| web:***www.objectmentor.com
800-338-6716* * * * * * * * **|

Responding to Arnuld...

> 1st of all i am newbie to what you call OOA-D. so i searched the
> archives of this newsgroup & i got this path:
>
> OOA-D -> UML -> OOP
>
> i also noticed one very interesting thing here about OOP step: OOP
> should be done preferably in a language that you will not use
> professionally, as told by "Lahman". i think he is right.

First, a clarification. The above is not really a path. UML is a
notation for OOA/D just as C++ or Smalltalk are notations for OOP. Thus
the result of doing both OOA/D or OOP is a model of the hardware
execution; one just happens to be a graphical notation while the other
is a text notation. (The notations are also at different levels of
abstraction.)

While I advocate learning OOA/D before attempting OOP and I advocate
using a "pure" OOPL like Smalltalk for learning OOP, I think those are
different things. Model-based development does use UML as <formal> a
step stone between OOA/D and OOP, but one does not /need/ to do OOA/D
formally in UML when developing software. The important thing about
OOA/D is the conceptual approach to problem solving, not the notation.

> reagarding OOA-D i see 4-5 recommendations but only 2 are available in
> my country: Booch & Rumbaugh
>
> i read some part of chapter 3 of "OOA & D with applications " by Grady
> Booch (around 10-12 pages). it feels *too* philsophical rather than
> practical, as if he is the king of "academic education" & doing Ph. D
> research on OOA-D or something like that. i dont even understand 10% of
> what Booch was talking about. it literaly swept above my head :-( . as
> per my experience, having a computer degree at hand ( i have a graduate
> degree) & writing code professionally are 2 very-very *different*
> things & Booch belong to the former side, at least this is is what i
> have felt.
>
> Does Rumbaugh writes in the same manner?

I don't think the issue is academic perspective for either author. Both
Booch and Rumbaugh had substantial practical experience and AFAIK
neither held a university teaching position. (Booch was building
computers and programming when he was in high school.) Booch spent most
of his career at Rational Software, which was founded as a consulting
company to industry. Before going to Rational, Rumbaugh spent quite
awhile at GE.

The OO paradigm is not intuitive if one is used to development using
traditional procedural approaches like Structured Programming. To
properly do OO development one must essentially forget everything one
learned about procedural development because it will just introduce
confusion. I suspect that what you perceive as an academic perspective
is primarily just a new way of thinking about software development.

In the Books category of my blog a point I make is that selecting an
OOA/D book is a personal thing. Different authors' styles can strongly
affect how well the message gets across. So the best way to select one
is to browse in the library first using the criteria I provide in the blog.

However, if the choice is as limited as you suggest that may not be an
option. In that case I can only suggest reading their books carefully
with an open mind. View the books as explaining a new way of thinking
about solving problems and try to understand the approach itself
regardless of how the approach compares to what you already know.

>
> UML authors like: Fowler, Page-Jones,Larman are easily available in my
> country (INDIA)
>
> i am learning C++ & not able to understand the OOP animal there. i only
> have done some non-professional Lisp Programming, like writing some
> trivial programmes & dont know any other language. what i want to say
> is, functional/procedural style comes naturally to me, this is exactly
> how i write trivial programmes & when i faced C++, i was completely
> blown-up into pieces. i dont even understand what exactly OOP is.
>
> i want to learn OOP and i dont want to read philosophical concepts. so
> i was thinking of buying Craig Larman's "Applying UML and Patterns".
> does anybody has any suggestions?

Larman's book is more practical in the sense that it is more about How
to apply an OO methodology while Booch's and Rumbaugh's books are more
about What an OO methodology is. IOW, Larman's book emphasizes the
/process/ of developing software more than the A&D principles.

Even if you find Larman's book easier to grasp because of the
familiarity of the overall processes like IID, I would suggest going
back to Booch and Rumbaugh and re-reading them with you new knowledge.


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

> I suggest you read Booch as if it was a novel. Don't try to understand
> or absorb it. Then read "Designing Object-Oriented C++ Applications
> using the Booch Method" by Martin and "Object-Oriented Design
> Heuristics" by Riel. These two books really opened my eyes. Then read
> Booch's book again and see what you think.

i dont have Booch, i have an illiegal pdf copy. book is too expensive,
nearly 2.5 times expensives than Rumbaugh's :-( if i need to purchase
then i will choose Rumbaugh. BTW, the other 2 books you mentioned, of
Reil & Robert Martin, are not available in India.

> A couple of other book suggestions, not strictly OO: "The Pragmatic
> Programmer" by Hunt & Thomas" and "Refactoring: Improving the Design of
> Existing Code" by Fowler.

these 2, also, are not available in India. BUT these are available:

"OBJECT ORIENTED SOFTWARE ENGINEERING" by IVAR JACOBSON
"UNIFIED MODELING LANGUAGE USER GUIDE" by BOOCH / RUMBAUGH /
JACOBSON
"UNIFIED SOFTWARE DEVELOPMENT PROCESS" by JACOBSON / BOOCH /
RUMBAUGH
"UML DISTILLED" by MARTIN FOWLER / KENDALL SCOTT
"FUNDAMENTALS OF OBJECT ORIENTED DESIGN IN UML" by MEILIR PAGE JONES
"APPLYING UML & PATTERNS" by CRAIG LARMAN
"EXECUTABLE UML - FOUNDATION FOR MODEL DRIVEN ARCHITECURE" by MELLOR /
BALCER
"OBJECT ORIENTED MODELING & DESIGN WITH UML" by MICHAEL BLAHA / JAMES
RUMBAUGH


> Read the post below as well:
>
> http://groups.google.com/group/comp....e_thread/threa
> d/d6e77220da9d415c/2d3fa888f4ec1652?tvc=2&q=group%3A*software.pattern s*+a
> uthor%3Adaniel#2d3fa888f4ec1652

"out of my head", the problem explained by OP (Frank O'Haram in that
thread) really looks like Ph. D. thesis to me, disconnected from the
real world.

> You don't have to intuit OO in order to take advantage of it:

what does that mean? ::

You don't have to intuit OO in order to "take advantage of" it:

OR

You don't have to intuit OO in order to "understand" it:


> In procedural code, we are taught to move duplicated blocks of code into
> a function. Those for whom procedural is "intuitive" are special in that
> they can spot duplication before it's in the code and create that
> function up front.
>
> People who intuit OO can spot duplicated decision code before typing it.
> However, like the beginner procedural person, you don't have to "get it"
> in order to take advantage of it after the fact.

i don't see any difference between these 2 explanations. may be because
of my newbie-ness.

> H. S. Lahman wrote:
> Responding to Arnuld...

> > OOA-D -> UML -> OOP
> >
> > i also noticed one very interesting thing here about OOP step: OOP
> > should be done preferably in a language that you will not use
> > professionally, as told by "Lahman". i think he is right.
>
> First, a clarification. The above is not really a path. UML is a
> notation for OOA/D just as C++ or Smalltalk are notations for OOP. Thus
> the result of doing both OOA/D or OOP is a model of the hardware
> execution; one just happens to be a graphical notation while the other
> is a text notation. (The notations are also at different levels of
> abstraction.)

that is a new thing you told me, C++ or programming langugaes are just
notations for OOP. WOW, i felt little abnormal at first but my
commen-sense agrees.

> While I advocate learning OOA/D before attempting OOP and I advocate
> using a "pure" OOPL like Smalltalk for learning OOP, I think those are
> different things. Model-based development does use UML as <formal> a
> step stone between OOA/D and OOP, but one does not /need/ to do OOA/D
> formally in UML when developing software. The important thing about
> OOA/D is the conceptual approach to problem solving, not the notation.

so one can learn OOA-D either from OOA-D or from UML or from both.
right?
(from books recommended here at comp.object)

> > reagarding OOA-D i see 4-5 recommendations but only 2 are available in
> > my country: Booch & Rumbaugh

>> [SNIP]


> The OO paradigm is not intuitive if one is used to development using
> traditional procedural approaches like Structured Programming. To
> properly do OO development one must essentially forget everything one
> learned about procedural development because it will just introduce
> confusion. I suspect that what you perceive as an academic perspective
> is primarily just a new way of thinking about software development.

may be, may be you are right. i can't say anything for sure.


> However, if the choice is as limited as you suggest that may not be an
> option. In that case I can only suggest reading their books carefully
> with an open mind. View the books as explaining a new way of thinking
> about solving problems and try to understand the approach itself
> regardless of how the approach compares to what you already know.


i have posted the list of books available in my country (i did not
mntion Rumabugh & Booch there), in response to Daniel T.'s reply. May
you please check them & remove the junk form there.i will be thankful
to you for that.

> Larman's book is more practical in the sense that it is more about How
> to apply an OO methodology while Booch's and Rumbaugh's books are more
> about What an OO methodology is. IOW, Larman's book emphasizes the
> /process/ of developing software more than the A&D principles.
>
> Even if you find Larman's book easier to grasp because of the
> familiarity of the overall processes like IID, I would suggest going
> back to Booch and Rumbaugh and re-reading them with you new knowledge.


new word: IID


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

your "Drano" always confused me :-) it is not even in the dictionary.
what is this "Drano"?

"arnuld"

"arnuld" <arnuld3{}> wrote:

> > Read the post below as well:
> >
> > http://groups.google.com/group/comp....e_thread/threa
> > d/d6e77220da9d415c/2d3fa888f4ec1652?tvc=2&q=group%3A*software.pattern s*+a
> > uthor%3Adaniel#2d3fa888f4ec1652
>
> "out of my head", the problem explained by OP (Frank O'Haram in that
> thread) really looks like Ph. D. thesis to me, disconnected from the
> real world.

Really. I used the exact concepts mentioned in a real world program the
day after I posted that message...

> > You don't have to intuit OO in order to take advantage of it:
>
> what does that mean? ::
>
> You don't have to intuit OO in order to "take advantage of" it:
>
> OR
>
> You don't have to intuit OO in order to "understand" it:

It means, you don't have to understand OO analysis and design in order
to use OO constructs in your code.

> > In procedural code, we are taught to move duplicated blocks of code into
> > a function. Those for whom procedural is "intuitive" are special in that
> > they can spot duplication before it's in the code and create that
> > function up front.
> >
> > People who intuit OO can spot duplicated decision code before typing it.
> > However, like the beginner procedural person, you don't have to "get it"
> > in order to take advantage of it after the fact.
>
> i don't see any difference between these 2 explanations. may be because
> of my newbie-ness.

That's the point. The only difference between the statements is the
nature of the duplication being removed.

If you have code like this:

if ( foo )
do_something();

and elsewhere you have:

if ( foo )
do_something_else();

You can see there is duplication in the code, but normal procedural
methods cannot remove that duplication. OO methods can.

Tell you what... I knew all about OO programming, but didn't *like* it until
I understood design patterns. Once I understood patterns, I was able to
really jump in to OO stuff.

Perhaps the same path would work for you. I suggest either "Head First
Design Patterns", or "Design Patterns Explained."


--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"arnuld" <arnuld3{}> wrote in message
news:1169285387.082343.183830{}v45g2000cwv.googleg roups.com...
> hai all,
>
> 1st of all i am newbie to what you call OOA-D. so i searched the
> archives of this newsgroup & i got this path:
>
> OOA-D -> UML -> OOP
>
> i also noticed one very interesting thing here about OOP step: OOP
> should be done preferably in a language that you will not use
> professionally, as told by "Lahman". i think he is right.
>
> reagarding OOA-D i see 4-5 recommendations but only 2 are available in
> my country: Booch & Rumbaugh
>
> i read some part of chapter 3 of "OOA & D with applications " by Grady
> Booch (around 10-12 pages). it feels *too* philsophical rather than
> practical, as if he is the king of "academic education" & doing Ph. D
> research on OOA-D or something like that. i dont even understand 10% of
> what Booch was talking about. it literaly swept above my head :-( . as
> per my experience, having a computer degree at hand ( i have a graduate
> degree) & writing code professionally are 2 very-very *different*
> things & Booch belong to the former side, at least this is is what i
> have felt.
>
> Does Rumbaugh writes in the same manner?
>
> UML authors like: Fowler, Page-Jones,Larman are easily available in my
> country (INDIA)
>
> i am learning C++ & not able to understand the OOP animal there. i only
> have done some non-professional Lisp Programming, like writing some
> trivial programmes & dont know any other language. what i want to say
> is, functional/procedural style comes naturally to me, this is exactly
> how i write trivial programmes & when i faced C++, i was completely
> blown-up into pieces. i dont even understand what exactly OOP is.
>
> i want to learn OOP and i dont want to read philosophical concepts. so
> i was thinking of buying Craig Larman's "Applying UML and Patterns".
> does anybody has any suggestions?
>
>
> "arnuld"
> --
> http://arnuld.blogspot.com/
> Linux registered user #439610 :: http://counter.li.org/
>

Responding to Arnuld...

> so one can learn OOA-D either from OOA-D or from UML or from both.
> right?
> (from books recommended here at comp.object)

One learns OOA/D from teachers, books, and/or mentors, not UML. Since
OOA/D is about higher level design of the software, it is at a higher
level of abstraction than the 3GL code that one deals with during OOP.
UML happens to be an abstract notation designed for the OOA/D so most
OOA/D books and courses use UML as a notation because it is a better
medium of communication for design issues.

> i have posted the list of books available in my country (i did not
> mntion Rumabugh & Booch there), in response to Daniel T.'s reply. May
> you please check them & remove the junk form there.i will be thankful
> to you for that.

> "OBJECT ORIENTED SOFTWARE ENGINEERING" by IVAR JACOBSON

A classic OOA/D book. Jacobson was the first prominent guru to champion
use case driven design.

> "UNIFIED MODELING LANGUAGE USER GUIDE" by BOOCH / RUMBAUGH /
> JACOBSON

This a book describing the UML notation semantics. It tells one how to
express a good design in UML but it doesn't tell one how to come up with
a good design in the first place.

> "UNIFIED SOFTWARE DEVELOPMENT PROCESS" by JACOBSON / BOOCH /
> RUMBAUGH

This is a process book. It provides a framework for organizing the the
activities in software development (e.g., practices like Incremental,
Iterative Development). While it has OOA/D examples, it is short on how
one conceives the designs.

> "UML DISTILLED" by MARTIN FOWLER / KENDALL SCOTT

This is an excellent introduction to the UML notation. It is an easy
read and it deals with all the notation elements one is likely to need
in practice. But, again, they are describing the notation, not how to
develop good designs.

> "FUNDAMENTALS OF OBJECT ORIENTED DESIGN IN UML" by MEILIR PAGE JONES

I haven't read this one.

> "APPLYING UML & PATTERNS" by CRAIG LARMAN

A good book with substantial OOA/D content but the focus is more one the
process of software development than on A&D methodology.

> "EXECUTABLE UML - FOUNDATION FOR MODEL DRIVEN ARCHITECURE" by MELLOR /
> BALCER

This happens to be the basic OOA/D reference for the methodology that I
use. However, their goal was to define an MDA profile (a subset of UML)
appropriate for translation (i.e., rigorous enough for full code
generation from UML models). So it is short on explaining Why one
models that way. OTOH, Mellor is the best application designer I have
ever known and the examples in the book are excellent.

> "OBJECT ORIENTED MODELING & DESIGN WITH UML" by MICHAEL BLAHA / JAMES
> RUMBAUGH

I have only read the original version that used OMT as the notation. I
assume only the notation has changed, so it is a classic OOA/D book.

> new word: IID

An acronym for Incremental, Iterative Development. The basic idea is to
break a project down into more manageable pieces (incremental) and
develop the overall project by doing each piece individually using the
same techniques (iterative). Most large applications have been
developed this way since the late '80s.

>>*************
>>There is nothing wrong with me that could
>>not be cured by a capful of Drano.
>
>
> your "Drano" always confused me :-) it is not even in the dictionary.
> what is this "Drano"?

Drano is a brand name in the US for a popular toilet and drain declogger
(caustic soda).


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

Daniel T. wrote:
> "arnuld" <arnuld3{}> wrote:
>
> > i want to learn OOP and i dont want to read philosophical concepts.
> > so i was thinking of buying Craig Larman's "Applying UML and
> > Patterns". does anybody has any suggestions?
>
> I suggest you read Booch as if it was a novel. Don't try to understand
> or absorb it. Then read "Designing Object-Oriented C++ Applications
> using the Booch Method" by Martin and "Object-Oriented Design
> Heuristics" by Riel. These two books really opened my eyes. Then read
> Booch's book again and see what you think.
>
> A couple of other book suggestions, not strictly OO: "The Pragmatic
> Programmer" by Hunt & Thomas" and "Refactoring: Improving the Design of
> Existing Code" by Fowler.
>
> > what i want to say is, functional/procedural style comes naturally
> > to me, this is exactly how i write trivial programmes
>
> This is right and natural. OO is a method for handling complexity, it is
> rather forced to try to use it in trivial applications.
>
> Read the post below as well:
>
> http://groups.google.com/group/comp....e_thread/threa
> d/d6e77220da9d415c/2d3fa888f4ec1652?tvc=2&q=group%3A*software.pattern s*+a
> uthor%3Adaniel#2d3fa888f4ec1652
>
> You don't have to intuit OO in order to take advantage of it:
>
> In procedural code, we are taught to move duplicated blocks of code into
> a function. Those for whom procedural is "intuitive" are special in that
> they can spot duplication before it's in the code and create that
> function up front.
>
> People who intuit OO can spot duplicated decision code before typing it.
> However, like the beginner procedural person, you don't have to "get it"
> in order to take advantage of it after the fact.
>
> When you see two switch statements that both switch off of the same
> variable, or two if statements that both check the same condition, just
> knock yourself on the head for not catching it beforehand and create
> polymorphic classes to remove the duplicated decision code.

Case/Switch bashing again, eh? [cue good/bad/ugly theme music]

The case (pun) is not so clear cut. Turning conditions into
polymorphism forces one to hard-wire an assumption of mutual exclusion
into the design. If later those options turn out not to be
mutually-exclusive, the case or IF statements are far easier to change
than polymophism because the location of the code is not based on a
taxonomy of subtypes. In procedural you don't shape your code based on
noun taxonomies such that if the taxonomy changes, it will not
significantly require moving code around. Generally any noun
taxonomy/classification system belongs in the database, not the code.

Further, case/switch/if statements are not more code than polymorphism.
Generally one is exchanging duplication on one dimension for
duplication in ANOTHER dimension. Duplicated decisions are often a sign
of a two-dimensional factor space, but code is generally linear and one
cannot project 2D onto 1D without making a sacrifice of some kind. The
OO books don't tell you this, implying it is a free lunch. They are
either lying or naive and should be spanked.

Using the overused "shape" examples, you have two "lists": lists of
shapes and lists of operations on those shapes. If you factor out the
duplication of one list you introduce duplication of another. OO'ers
don't bother to count the repeated method list as "duplication" because
they are brainwashed to ignore such duplication.

Scientific observation of code and code change patterns often does not
back OO's claims (unless you accept their rigged change pattern
frequencies at face value).

-T-