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


Robert Martin wrote:
On 2007-01-23 15:02:42 -0600, "topmind" <topmind@xxxxxxxxxxxxxxxx> said:

Robert Martin wrote:
Procedural programming allows you to add new functions without changing
the existing data structures. OO allows you to add new data structures
without changing the existing functions. You need both capabilities.

You mean adding functions and "subtypes" without changing existing
code?

Sometimes you have functions that can deal with many different kinds of
data structures. Often these functions will have a switch/case
statement in them for the parts of those data structures that vary.
You can add new functions any time you like, without having to make any
changes to the data structures.

"Kinds" of data structures? I use tables (given a choice). There is
only one kind for relational fans (and maybe maps for small local
things). You are trying to sell refridgerators to eskimos.


OO gives you the opposite ability. Sometimes you have functions that
deal with with a particular kind of data structure. Often these data
structures have variants. If you treat them as OO subclasses then you
can add new variant data structures any time you like without having to
make any changes to the existing functions.

There are table-driven ways to do such and even file-driven ways.

Of course. OO just hides these techniques behind a language syntax.

The difference is minor, and like I describe in a nearby message, the
OO approach locks you into mutual-exclusiveness. It is much harder to
undo M.E. with poly than with p/r. The syntax is simpler for poly
because it *leverages* the ME assumption. P/R dates ME, not marries it
such that the OO ME divorce is a painful one.


I don't find a
practical need for such very often in biz apps, though.

I have seen you make that startling statement many times. I make use
of this ability of OO all the time in business applications. Perhaps
we just have very different world views.

I guess so. OO'ers see hierarchies and M.E. lists where I see sets. I
could force domain nouns into taxonomies, but they are artificial and
have many change spike problems. Your "employee types" as described in
my review of your book is a pretty good example of this. And a real one
witnessed by me: rank and file employees got sales commissions. It is
not a change I dreamed up.

I challenge you to produce a half-dozen biz taxonomies where ME or
trees are a safe bet. Just list the taxonomies in outline format:

Node 1
- foo
- - bar under foo
- floo
Node 2
- etc...

(You can multipley the dash numbers by 2 if it helps improve the
visual.)


But you forgot to mention another change pattern: loss of mutual
exclusiveness. If 2+ options change to no longer be mutually exclusive,
then procedural fairs better. It is a smaller change: just change the
CASE to IF statements. With polymorphism you have to move code to
different named modules, and I give that a much higher change cost
score.

On the contrary the the change in an OO program is remarkably simple.
One simply puts the objects that represent the non-exclusive options
into a composite.

That is not a simple change compared to p/r. Plus, in the real world
the DB already has the necessary "structures". Repeating them in the
app language is double duty.

I find it easier to manage taxonomies in tables than in code (if they
are small and local, then it does not impact the argument either way
except that procedural is easier for local stuff IMO). It is hard to
search, sort, and sift code. Plus, normalization rules produce more
consistency rather than every OO fan invent their own.

OO has *no* real normalization rules so far. It is shanty town
building. Relational has "building codes". Thus, relational gives me
the power of sets to manage noun "taxonomies", and the consistency of
normalization, and the built-in collection handling abilities. OO
lacks.


--
Robert C. Martin (Uncle Bob) | email: unclebob@xxxxxxxxxxxxxxxx

-T-

.

Relevant Pages

  • Re: Boochs book feels too philosophical rather than practical?
    ... OO allows you to add new data structures ... OO approach locks you into mutual-exclusiveness. ... If the employee falls into a category ... Just list the taxonomies in outline format: ...
    (comp.object)
  • Re: Boochs book feels too philosophical rather than practical?
    ... OO allows you to add new data structures ... It talks about different types of payment classifications. ... This allows an Employee object to hold a referent to a paymentClassification object. ... Just list the taxonomies in outline format: ...
    (comp.object)
  • Re: OO is the new Go-To (was: Biz Tree Challenge)
    ... Robert Martin wrote: ... Only 1 thru 3 directly remove duplication IIRC. ... existing data structures without changing the data structures. ... We present tools for dealing with ALL change scenarios. ...
    (comp.object)
  • Re: OO is the new Go-To (was: Biz Tree Challenge)
    ... evangalists like Robert Martin and Fowler and Meyer that owe us better ... Procedural programming facilitates other kinds of changes. ... Specifically OO makes it easy to add new data structures to existing functions without changing the functions whereas procedural makes it easy to add new functions to existing data structures without changing the data structures. ... We don't elevate the importance of OO-favoring change scenarios. ...
    (comp.object)