A simple question for Abstract Class

[Luc The Perverse]

Null objects are useful. The person at Sun writing this class apparently
forgot that.

Huh? You can't set abstract objects to null?

I had not looked into this but that doesn't make any sense at all.

I thought the beauty of OOP (transcending language) was being able to write
code like this.

AbstractAnimalClass[] pets = {null, new Dog(), new Cat()};
for(int i=0;i<pets.length;i++)
if(pets!=null)
pets.speak(); //Make some noise!

 

[Chris Uppal]

Luc The Perverse wrote:

[me:]

Huh? You can't set abstract objects to null?

You misunderstand -- which is understandable ;-)

"null objects" have nothing to do with the "null" value in Java. They are
objects (real, proper, objects) which implement a protocol shared with other
objects (For "protocol" in Java read "interface or type") by performing no
action.

I thought the beauty of OOP (transcending language) was being able to
write code like this.

AbstractAnimalClass[] pets = {null, new Dog(), new Cat()};
for(int i=0;i<pets.length;i++)
if(pets!=null)
pets.speak(); //Make some noise!

Yes, sort of. You have the polymorphism bit down pat, but notice how Java's
null value is /not/ polymorphic with anything. It's a singularity in the
semantics, and causes a deal of extra work and verbiage. The same idea
expressed using null objects would look like:

AbstractAnimalClass[] pets = { new NullAnimal(), new Dog(), new Cat() };
for (int i = 0; i < pets.length; i++)
pets.speak();

Not a very good example, I admit, but at least it illustrates the absence of
ugly and arbitrary is-null tests.

If you look on the Web for more info, then don't restrict your search to
Java -- it's not a language-specific concept. Indeed, it seems to be rarely
used in Java; I don't know to what extent that's because Java's inflexible type
system makes it awkward, or because (speaking statistically /only/ !) Java
programmers tend to be relatively unsophisticated.

-- chris

P.S. On re-reading this, I should perhaps make it clear that I'm not
advocating a wholesale replacement of Java's null value with null objects!

 

[Dale King]

[...] You claim it reduces functionality, but there
really isn't a plausible use for an instance of WindowAdapter.

Sure there is. Once you've got working Null objects (or deaf objects) then
uses crop up all over the place. E.g. dummying stuff out during development,
debugging, and testing (these form the main uses, IMO). As a default for
configurable/pluggable architectures. As "safe" placeholders to replace the
normal listener during updates which could generate unwanted notification. As a
way to avoid ugly if (xxx != null) tests all over the place. And so on...

Null objects are useful. The person at Sun writing this class apparently
forgot that.

Null objects are useful. The greatest use for them is for subclassing
and having default implementations.

There are also uses for instances of null objects. Mostly in cases where
you are required to provide an implementation of an interface to use an
API. When the use of the interface is completely optional there is not
as much use.

In the case of WindowAdapter I can't see any great use for them. There
is no reason to actually add one as a listener to a window, because it
is the same as not adding anything.

But let's say you do need a do nothing implementation of WindowAdapter.
Then the fact that they made it abstract is only the difference between
these two expressions, which is not rally valid to claim as a "reduction
in functionality"

new WindowAdapater()

vs.

new WindowAdapater() {}

 

[Prem]

Could it be a language design issue, rather than a design error? I mean
if WindowAdapter had not been abstract, we would have been able to
instantiate objects of that type - objects whose methods did absolutely
nothing. Does this imply something that goes against the inherent
object-orientedness of java in some way? Or could it result in more
potential runtime errors ?

 

[Chris Uppal]

if WindowAdapter had not been abstract, we would have been able to
instantiate objects of that type - objects whose methods did absolutely
nothing. Does this imply something that goes against the inherent
object-orientedness of java in some way? Or could it result in more
potential runtime errors ?

No to both, I think.

How an object behaves when sent a message (when a method is invoked) is /it's/
affair, not anyone else's -- providing that it meets the terms of whatever
formal or informal contracts make up the overall design. If it does nothing
(and if doing nothing is allowable in the specific circumstances), then that's
valid and natural OO. Just another object doing its own job in its own way.

-- chris

 

[Andrew McDonagh]

Could it be a language design issue, rather than a design error? I mean
if WindowAdapter had not been abstract, we would have been able to
instantiate objects of that type - objects whose methods did absolutely
nothing. Does this imply something that goes against the inherent
object-orientedness of java in some way? Or could it result in more
potential runtime errors ?

No, it would just be a miss named class.

It would be better named NullObjectWindowAdapter - or some such, to
highlight that the class was implementing the NullObject design pattern.

See http://www.industriallogic.com/xp/refactoring/nullObject.html