Re: Booch's book feels too philosophical rather than practical?


Daniel T. wrote:
"arnuld" <arnuld3@xxxxxxxxx> 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.software.patterns/browse_thread/threa
d/d6e77220da9d415c/2d3fa888f4ec1652?tvc=2&q=group%3A*software.patterns*+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-

.