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

"arnuld" <arnuld3@xxxxxxxxx> wrote:

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

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