Null objects and DeafObject

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Null objects and DeafObject

Fernando Rodríguez
Hi,

Assume I have an instance variable that will contain a Book object.
I'd like to initialize it to some sort of null Book. A book whose
methods are all NOPs.

Should I create a subclass for this purpose or is this what DeafObject
is for?

Thanks


Reply | Threaded
Open this post in threaded view
|

Re: Null objects and DeafObject

Schwab,Wilhelm K
Fernando,

> Assume I have an instance variable that will contain a Book object.
> I'd like to initialize it to some sort of null Book. A book whose
> methods are all NOPs.

Getting pedantic (to a purpose) for a moment, it is not possible to have
all methods do nothing; even a ProtoObject is required to exhibit some
behavior.  If your goal is to build something that "learns" new
behavior, you should be certain that you really want to do that, and
then early on verify that it will work in a deployed executable should
that be your goal.

It seems more likely that good initialization and unit testing will be a
more direct route to something that works.  You can rough in some very
simple test cases and invoke them directly from the CHB/SB.  Since you
expect failures early on, it makes sense to include comments like

    SomeTestCaseSubclass new testSomething

in methods as you add them.  "When" the test fails, you will go directly
to the walkback and you will not need to fuss around with resetting the
test browser, selecting which failure to debug, etc.  When you have
reasonable expectations of tests passing, the SUnitBrowser becomes a
great tool.  However, when I find a change has given me a stubborn test
or two, I still fall back on the do-it approach.


> Should I create a subclass for this purpose or is this what DeafObject
> is for?

I prefer to use DeafObject in situations that involve complex
interactions and short time periods that probably lead to a graceful
exit as the goal.  As an example, I had a dialog box that I could not
test via the Show command, and adding a DeafObject in the right place in
my #ideModel method (see the archives) got it to, well, shut up<g>, long
enough to just go away with some dignity.  IMHO, you should think very
carefully about using DeafObject in code you intend to ship.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Null objects and DeafObject

Can Altinbay
In reply to this post by Fernando Rodríguez
"Fernando" <[hidden email]> wrote in message
news:[hidden email]...

> Hi,
>
> Assume I have an instance variable that will contain a Book object.
> I'd like to initialize it to some sort of null Book. A book whose
> methods are all NOPs.
>
> Should I create a subclass for this purpose or is this what DeafObject
> is for?
>
> Thanks

The first step IMHO is to ask why you want to do this.  Step back and ask
why you want to approach it that way.
You may already have done that, but we don't know that.  My purpose in
asking is that we need to solve the problem, not come up with ways to do a
particular task.  If your approach is in fact a good one, we can deal with
it at that level.


Reply | Threaded
Open this post in threaded view
|

Re: Null objects and DeafObject

Reinout Heeck
In reply to this post by Fernando Rodríguez
Fernando wrote:
>
> Assume I have an instance variable that will contain a Book object.
> I'd like to initialize it to some sort of null Book. A book whose
> methods are all NOPs.
>
> Should I create a subclass for this purpose or is this what DeafObject
> is for?

Yes and yes :-)

I guess it depends on your preference and on which phase your project is in.

DeafObject is nice to do exploratory programming without having to write any
scaffolding. My preference is to refactor to using a specialized class when
the code has to go beyond being of exploratory quality.



HTH,

Reinout
-------


Reply | Threaded
Open this post in threaded view
|

Re: Null objects and DeafObject

Fernando Rodríguez
In reply to this post by Schwab,Wilhelm K
On Sun, 13 Mar 2005 13:24:55 -0500, Bill Schwab
<[hidden email]> wrote:


>Getting pedantic (to a purpose) for a moment, it is not possible to have
>all methods do nothing; even a ProtoObject is required to exhibit some
>behavior.  If your goal is to build something that "learns" new
>behavior, you should be certain that you really want to do that, and
>then early on verify that it will work in a deployed executable should
>that be your goal.

No that's not what I had in mind. Actually I'm not sure what you mean
with learning new behavior...

I'll explain myself with a concrete example, it should make things
more obvious.

In an application (non St) I have a series of textboxes for user
input. Most of these textboxes have a 'checker' attached that verifies
if the text entered is correct: no spelling errors, too little text,
no text, way too much text, weird characters, etc...

So I have a hierarchy of Checker classes taht use the composite
pattern, so you can check for several different conditions.

However, a textbox that doesn't need to be checked is a specila case
and needs to be handled differently. If you create a Checker subclass
that is a null checker (all methods in the Checker protocol are NOPs),
this special case disappears. Now ALL textboxes have a checker, those
that don't need it, have a null one.

 It's the null element for a given protocol, just like zero is the
null element for the 'addition protocol'.

I find this idea extremely useful:
a) It removes special cases
b) It's a safe initial value
c) It's great during debugging: when adding a new hierarchy to an
app., start with the Null version and see if the design works and
makes sense before getting into the hairy details of the
implementation of the protocol.

Dolphin's DeafObject seems to be a 'universal null class' that nops
almost every protocol, and not just a specific one.  I fear that this
might introduce subtle bugs...


Reply | Threaded
Open this post in threaded view
|

Re: Null objects and DeafObject

Chris Uppal-3
Fernando,

> However, a textbox that doesn't need to be checked is a specila case
> and needs to be handled differently. If you create a Checker subclass
> that is a null checker (all methods in the Checker protocol are NOPs),
> this special case disappears. Now ALL textboxes have a checker, those
> that don't need it, have a null one.
[...]
> Dolphin's DeafObject seems to be a 'universal null class' that nops
> almost every protocol, and not just a specific one.  I fear that this
> might introduce subtle bugs...

DeafObject would not be suitable for the example you gave.  What DeafObject
does is /ignore/ all messages, not to provide a /null implementation/ of all
messages.  Sometimes the difference matters, especially when the method is
expected to answer a useful value.

In your example, assuming that the checking method is called #isTextOK, the
null implementation would probably be to answer true.  However if you used a
DeafObject in that context it would ignore #isTextOK, and therefore would
actually answer itself.  The answer would probably then be passed into some
#isTrue: or #isFalse: block, and the system would then throw an error because
the DeafObject is not a Boolean.

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: Null objects and DeafObject

Schwab,Wilhelm K
In reply to this post by Fernando Rodríguez
Fernando,

> No that's not what I had in mind. Actually I'm not sure what you mean
> with learning new behavior...

learning behavior == add methods; the problem is to make their content
reasonable, except, of course, when a programmer is standing by to
assist, as in the debugger's Implement-in command.


> I'll explain myself with a concrete example, it should make things
> more obvious.
>
> In an application (non St) I have a series of textboxes for user
> input. Most of these textboxes have a 'checker' attached that verifies
> if the text entered is correct: no spelling errors, too little text,
> no text, way too much text, weird characters, etc...
>
> So I have a hierarchy of Checker classes taht use the composite
> pattern, so you can check for several different conditions.
>
> However, a textbox that doesn't need to be checked is a specila case
> and needs to be handled differently. If you create a Checker subclass
> that is a null checker (all methods in the Checker protocol are NOPs),
> this special case disappears. Now ALL textboxes have a checker, those
> that don't need it, have a null one.

You are trying to create a software "yes man" (think of the effect on
middle management<g>).  IMHO, you should develop something along the
lines of AlwaysSearchPolicy along side of the more elaborate classes; it
should be by far the easiest of the classes to maintain.  Unit tests
should be sufficient to help keep it working, but you could also use the
protocol browser to establish a textChecker protocol with the required
methods; note that it will stub methods with #notYetImplemented or
somehting like that.  With something analgous to SearchPolicy, I would
simply make up some good tests and make them better any time something
slipped through them.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]