Re: How to Introduce OO to Structured-Method IT Person?

From: Topmind (topmind_at_technologist.com)
Date: 11/13/04 

Date: 12 Nov 2004 18:33:28 -0800

Universe <> wrote in message news:<tt5uo0tbcs8uf3b0ue35brm2er3fakcdh9@4ax.com>...
> gohbn2000@yahoo.com.sg (BoonNam Goh) wrote:
>
> > 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?
>
> Yes, but it is akin for many projects to prematurely doing performance
> tuning--attempted before requirements task logic has been completed.
>
> I suggest that *modelling*, or the same thing *abstracting* -
> eliminating things irrelevant to the requirements and representing or
> enhancing things relevant to project requirements - the project domain
> and requirements should be the starting point of virtually *all*
> software development.
>
> The essence of OO sw engineering is reducing complexity by modelling -
> abstracting* - major requirements relevant role responsibilities, in
> the domain and in the requirements, as a network of collaborating
> object modules.

Keep in mind that *relevancy is relative*. There often is no
single "right" global viewpoint. Different departments might
want different viewpoints of the same info. Relational modeling is
better able to deal with this than OOP in my opinion because
one does not hard-wire a single viewpoint around domain
nouns as they often do in OO modeling. A viewpoint in
relational usage tends to be local to needs, not global.
This better reflects the modern, complex real world.

>
> "Object-oriented [OO] programming. A program execution
> is regarded as a physical model, simulating the behavior
> of either a real or imaginary part of the world...The
> notion of a physical model should be taken literally."
> ~ Computerized physical models
> by Madsen, Moeller-Pederson, Nygaard (co-founder of OO)

Nygaard was mostly a physical modeller by trade. The problem
is that computers can *transcend physical reality*.
For example modern book indexing systems
can index things by multiple viewpoints (categories)
that the Dewey Decimal hierarchical placement system could not handle.
We cannot order physical books by multiple viewpoints, but
we can with virtual books. OO philosophy is often
stuck in the 60's in this regard. It has stuck to the
physical world model instead of transcending it
using what computers *can* do if given the chance. It can be said
OO is the Plato view of the world while relational is the
Einstein view of it.

-T-
oop.ismad.com