How to Introduce OO to Structured-Method IT Person?

From: BoonNam Goh (gohbn2000_at_yahoo.com.sg)
Date: 11/08/04 

Date: 7 Nov 2004 21:21:38 -0800

I am looking into how to introduce OO to a Structured-Method Person
(ie. IT professional who is new to OO but who has done things via
structured or functional decomposition method).

Appreciate advice:
Can I say as a simplification, that one of the first benefits of OO is
that it allows for "normalization" of methods -- similar to
logical-data-modelling's (ie. LDM's) normalisation of data?

Let me explain:
In LDM, data is normalised to 3rd normal form (3NF) where there will
be no duplication of data items in the various data entities.

Similarly, for OO, when we analyse the objects and draw them into a
class diagram and use GRASP (or other similar methods) to assign
methods to relevant classes, we are sort of also "normalising" the
methods so that algorithms only appear in one place in the whole
system -- ie. there is no duplication. This automatically makes all
algorithms reuseable as "subroutines".

Eg. In functional decomposition, we could have two processes/modules
to develop in a system - say, "buy book" and "catalog book". When we
do the functional decomposition, we may end up with duplicate
algorithms for ValidateISBNCheckDigit in each module and we have to
realise that there are such duplicates before we can move them out
into a common subroutine.

In the case of OO, we would have naturally put ValidateISBNCheckDigit
as a method into a suitable class (eg. "Book") the first time we did
an analysis for the first module - say, "buy book". When we do OO
analysis of the 2nd module - "Catalog Book", the
ValidateISBNCheckDigit method would again naturally go to the same
class. Creation and reuse of a "subroutine" would come about
naturally.

Does the above sound valid as a sort of simplification to one aspect
of OO?