Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm
From: "Philip Hart" <hartpj@ubusiness.co.uk>
To: <struts-user@jakarta.apache.org>
Subject: RE: can a ActionForm be ever null in Action class
Date: Sat, 3 Feb 2001 12:59:45 -0000
Message-ID: <001701c08de1$2ea99e80$9dbe063e@usbusiness.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <022201c08da4$8408dc20$5add0341@frmt1.sfba.home.com>
Importance: Normal

Hi Martin (et al)

The Null Object pattern is a really simple and neat way to eliminate the
need to test for null object references before making a method call. You
know the typical sort of thing:

	SomeActionClass foo = null;
	...
	foo = ...	// Some possible assigment, or not, depending on code.
	...

	// Make sure not null before sending method
	if (foo != null)
	{
		foo.doSomething();
	}

Instead, one uses the power of inheritance to create a sibling class whose
entire "rasion d'etre" is to do nothing. For example, in adapting the above
case, one could have the following class hierarchy:-

				---------------------
				|                   |
				| ActionParentClass |
				|                   |
				---------------------
				| doSomething()	  |
				---------------------
						|
						^
					     / \
					     ---
						|
			-------------------------------------
			|						|
	---------------------				---------------------
	|                   |				|                   |
	| SomeActionClass   |				| NullActionClass   |
	|                   |				|                   |
	---------------------				---------------------


The required "business logic" is placed in the SomeActionClass.doSomething()
method, whereas the NullActionClass.doSomething() method is left empty.
Thus, a call to the doSomething() method will either execute the business
logic or do precisely nothing, depending on the *actual* class to which the
message is sent.

Now, whenever a variable is declared and initialised, it is assigned a
reference to an instance of the Null Class rather than just the value
"null". So, the code above is simplifed to the following:-

	ActionParentClass foo = new NullActionClass();	// Object must be of common
superclass
	...
	foo = ...	// Some possible assigment, or not, depending on code.
	...

	// Execute method
	foo.doSomething();	// No need to caheck for null value.


This might not seem a big deal, saving but a few lines of code; but think
how many times one has to write such test code! Or, indeed, how many times
one forgets to write such code!!!!! This aproach is much more robust.


An additional spin on this technique is to make the NullActionClass a
Singleton, such that there is exactly one instance of the NullActionClass
which is shared. After all, if it doesn't really do anything, why do you
need more than one instance cluttering up the memeory space!!!


I hope you find this short explanation helpful (even if it's not up to the
standard of pro authors :-), and can see how it might be useful in avoiding
the dreaded NullPointerException.


Happy Strutting,
Philip Hart


> -----Original Message-----
> From: Martin Cooper [mailto:martin.cooper@tumbleweed.com]
> Sent: 03 February 2001 05:45
> To: hartpj@ubusiness.co.uk
> Subject: Re: can a ActionForm be ever null in Action class
>
>
> Philip,
>
> Could you expand on this a little? I don't have "Patterns in Java", and am
> not familiar with the Null Object pattern, but I'd like to understand what
> you're suggesting.
>
> Thanks.
>
> --
> Martin Cooper
> Tumbleweed Communications
>
> ----- Original Message -----
> From: "Philip Hart" <hartpj@ubusiness.co.uk>
> To: <struts-user@jakarta.apache.org>
> Sent: Friday, February 02, 2001 12:47 PM
> Subject: RE: can a ActionForm be ever null in Action class
>
>
> > Hi All
> >
> > Just a thought, but couldn't we use the Null Object pattern (pp 365-369,
> > Patterns in Java Volume 1, Mark Grand) as a default for this scenario?
> >
> > It would mean that there would be no further need to make an
> explicit test
> > for null, as calling the corresponding method will have no effect.
> >
> > As I said, just a thought. In any case, keep up the brilliant work.
> >
> >
> > Cheers,
> > Philip Hart
> >
> > > -----Original Message-----
> > > From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> > > Sent: 02 February 2001 17:42
> > > To: struts-user@jakarta.apache.org
> > > Subject: Re: can a ActionForm be ever null in Action class
> > >
> > >
> > > Anand Raman wrote:
> > >
> > > > Hi guys
> > > >
> > > > I noticed in the struts-example application a check to find whether
> the
> > > > ActionForm "form" passed to the perform method of Action class
> > > is null or
> > > > not.
> > > >
> > > > Is it really necesarry.. I am not able to come up with a situation
> like
> > > > this.. According my knowldge a ActionForm is always populated before
> the
> > > > perform method is called on the Action class..
> > > >
> > > > can anyone please enlighten this situation
> > > >
> > >
> > > It will be null if and only if you have not associated an input form
> with
> > > this action.  Otherwise, an ActionForm will have been created and
> > > populated
> > > if it didn't already exist.
> > >
> > > Now, of course, since I wrote the entire app in this case, I
> > > *know* that the
> > > configuration file is correct, and the null checks are not strictly
> > > necessary.  On the other hand, if I was writing actions and
> > > someone else was
> > > building struts-config.xml, I'd generally do a little defensive
> > > coding like
> > > this to protect myself from configuration file mistakes ...
> > >
> > > >
> > > > Thanks for ur time
> > > > Anand
> > >
> > > Craig
> > >
> > >
> > >
> >
>
>
>