Re: Retrieving unnecessary data

On Feb 18, 9:18 am, Robert Martin <uncle...@xxxxxxxxxxxxxxxx> wrote:
On 2008-02-15 12:15:52 -0600, topmind <topm...@xxxxxxxxxxxxxxxx> said:





Robert Martin wrote:
On 2008-02-14 15:00:13 -0600, topmind <topm...@xxxxxxxxxxxxxxxx> said:

These are the kinds of problems one encounters when they try to use
OOP to model domain nouns. Modeling domain nouns for business apps is
a road to bloat, hell, or both.

That depends on what you mean by "domain noun". If you organize your
nouns around data (e.g. what things _have_) then I'd agree with you.
If, on the other hand, you organize your domain nouns around behavior
(e.g. what things _do_) then I wouldn't.

One can generally shift the same stuff to be data-centric or behavior-
centric. They are just about completely interchangable.

Quite. Indeed, I think the Mealy-Moore equivalence is the proof of that.

Is it better to ogranize your nouns around data, or around behavior?
In my view we need some of both. There are aspects of a system that
ought to be centered on data. There are other aspects that ought to be
centered on behavior. Procedural helps decouple one. OO helps
decouple the other. I like having options.

Then why not add Functional Programming, Logical Programming, etc.
into the mix? They give you more options. It's back to our same ol'
discussion on where to draw the line on paradigm potpourri
programming. I just haven't seen OO add much value to rank-and-file
data-driven biz apps. I'm from the Show Me state of mind.

-T-
.

Relevant Pages

  • Re: Retrieving unnecessary data
    ... OOP to model domain nouns. ... Modeling domain nouns for business apps is ... a road to bloat, hell, or both. ...
    (comp.object)
  • Re: Retrieving unnecessary data
    ... OOP to model domain nouns. ... a road to bloat, hell, or both. ... There are aspects of a system that ought to be centered on data. ... Procedural helps decouple one. ...
    (comp.object)