Re: How much oop is too much oop?


"Jerry Coffin" <jcoffin@xxxxxxxxx> wrote in message
news:MPG.1cd9559b24a41d239896b6@xxxxxxxxxxxxxxxxxxxxx

>> The principle
>> of making operations failsafe, is in no way violated by simply
>> providing quick tests to see if you know they're going to fail in
>> advance.
>
> Providing both violates the general notion of an interface being
> complete yet _minimal_.

Ah well. Unfortunately these are not hard and fast concepts.
"minimal" to you is obviously "subminimal" to me if it forces me to
omit a two line method whose absence prevents me doing something in
milliseconds which would bypass another task taking 10 minutes and
then failing.

> [ ... ]
>
>> Of course you can. For an object with N boolean attributes
>> which
>> are important to you, you can create 2^N derived classes so that
>> you
>> have one with every possible combintion of attributes. I don't
>> envy
>> you writing a program that way though.
>
> You seem to have carefully snipped and ignored the most important
> point here: if N is large enough for this to matter, your design
> is
> _almost_ certainly screwed up from the beginning.

Again I disagree. Some perfectly reasonable objects have very many
attributes - some much more complicated than Boolean.

> On the _rare_ occasion that N really is unavoidably large, ...

It may be rare for you - I have lived with it every day for fifteen
years or so: for example arrays of thousands of music items
including notes, rests, dynamics, bar-lines, clefs, keys,
time-signatures, and many others with some properties in common and
others which are different. A music item with what you describe as
a "minimal interface" would be completely useless to me however many
levels of derivation were available.

> you don't need to (at least directly) write N^2 classes

It's 2^N for N two-valued atributes - rather bigger than N^2 for
N>4.

> to handle the
> job. Rather, you can write N base classes, and then generate the
> N^2
> combinations thereof via templates.

2^N combinations. [That's 4 giga-combinations for 32 boolean
attributes.]

And that is supposed to be somehow better than a single class with N
"isThisThatOrTheOther()" members? Just to "minimise the interface"
(of each)? This is dogma gone mad!

> [ ... ]
>
>> Consider this: the strength of object orientation comes from the
>> fact that it models the objects and procedures of real life.
>
> Quite the contrary. This is, at most, one of many strengths of OO
> programming -- and a rather minor one at that, IMO.
>
>> In
>> real life you know that if you have a stack of regular
>> pentagons,
>> then you can't tile the plane with them. You don't start
>> trying.
>> In real life you *can* look in the varnish pot to see if it is
>> empty
>> and you don't (at least I don't) start doing a long operation
>> which
>> a few hours later will require it to be full.
>
> If this analogy really applies to your code, then your code is
> probably utterly and irretrievably broken.

It's selling quite well, and satisfying thousands of people thanks.
And I have been maintaining it and developing it since well before
the first release over 10 years ago. It embraces hundreds of
classes which work together. Design decisions change occasionally
in the light of experience, and even in the light of
object-orientation ideas, but only if they're going to be helpful.

The fact that it patently *isn't* broken, is why I can say all these
things with conviction. The fact that it *is* object oriented
(despite what you would obviously consider dire shortcomings in its
adherence to dogma) is what has allowed me to maintain it and make 8
major releases over that period.

> In real life, there are physical constraints on nearly everything.
> If
> your code is intentionally simulating those physical constraints,
> well and good

It has to. Music syntax (a real life phenomenon for me) is
horrendously irregular.

> -- but in the case of such a simulation, you almost
> certainly do NOT want to add "intelligence" above or beyond what
> the
> physical object possesses, or your simulation is broken.

I am not doing that. Unless you regard as unnecessary intelligence
a note knowing that it is a note and a bar-line knowing that it is a
bar line (and divulging that information when asked).

> Under nearly all other circumstances, your code should not suffer
> from the physical constraints of real life. There's only one
> physical
> constraint that applies to most well-written code: memory
> availability....

This is not a problem these days. It was in v1 for Win3.1. I
started out by taking extreme care and have gradually relaxed it
where other considerations are more important. Today memory has
outstripped my requirements by orders of magnitude. [But in my
music items I do make very tight use of memory by using bit fields -
for example only 3 bits for the degree of the scale 1=doh,
2=re,...7=te, and 0 = a rest. And I am not going to change that -
so .NET is out :-( ]

A much worse physical constraint for me is speed of the code in the
drawing module: drawing a couple of pages of densely written music
on the screen is non-trivial even with today's graphics cards. [The
real test comes when the music is playing back on one thread and a
cursor is following it on screen in another, and then it has to
scroll by a page without interupting the play back.] This is why
I use arrays of items rather than other structures: slow to insert
during editing, but fast to read during drawing and play-back.
[Another design decision based on physical constraints other than
memory.]

> Real-time code adds the possibility of the processor not being
> fast
> enough -- but, again, measuring this ahead of time is rarely a
> feasible solution to anything.

In my case "real time" means editing music and redrawing the screen
in less time (approximately) than it takes to blink, and not having
hour glass cursors roaming the screen for - err - hours.

I use performance counters in the debug version to identify any
critical problems. I also test on a win98 first edition laptop,
which I haven't replaced for exactly that reason.

> To summarize: having such a limitation that needs to be checked
> for
> ahead of time is a strong indication that the code is broken.

There is a semantic subtlety here. It doesn't *need* to be if one
is prepared to put up with the wait. But why should I make my users
put up with the wait when they don't have to? (And for the music
program I mention above it may only be half a second - but even that
makes it feel sluggish and unresponsive if expended unnecessarily
too often.)

Either

if( X.isANote() ) failurecode = Music.doSomething( X) ;
else failurecode = NOT_A_NOTE;

or

FAILURECODE MUSIC::doSomething( const ITEM &X )
{
if( !X.isANote() ) return NOT_A_NOTE;

//.......

}

(or even both!) can be much faster than any option where
X.isANote() is "forbidden"

If only 90% of the possible failure reasons are caught in a fraction
of the time by quick tests than trying to do everything first time,
then it makes an awful lot of sense.

Of course I know I can get round it by writing the 4 billion derived
classes. But even with derived classes I'd still have to get them
into arrays. An array of pointers to base classes would be an OO
way - but looking after memory fragmentation would then start to
become a major priority. [The program already does *some* of this
for objects of unavoidably variable size.]

But short of this, telling customers that it is ok that it is
sluggish because it is more strictly object-oriented (according to
some people's criteria) is not going to make me my living. Even
worse, telling them that the method which works faster only does so
because the fast method is "irretrievably broken" would be a very
good joke.

Dave
--
David Webber
Author MOZART the music processor for Windows -
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm


.

Relevant Pages

  • Re: How much oop is too much oop?
    ... Providing both violates the general notion of an interface being ... > fact that it models the objects and procedures of real life. ... there are physical constraints on nearly everything. ... constraint that applies to most well-written code: memory ...
    (microsoft.public.vc.language)
  • Re: Thin Man.
    ... > think my memory is bad on rmp you should see me reintroducing myself to ... > people over and over again in real life.. ...
    (rec.music.phish)
  • [fw-wiz] Certification ?
    ... I'm gagging on this "certification" thing. ... REAL life not only involves memory of facts but memory of where to LOOK for answers and finding them in what ever resource is available. ... Cert Smert!! ...
    (Firewall-Wizards)
  • Re: hawkeye game
    ... >>>I'm not sure I saw that one, but it sounds like in real life it would be ... >> A pencil and paper or a good memory will get you loads of points. ...
    (uk.sport.cricket)