CODEWITHSUNDEEP
java
Dusan
Dusan

Reputation: 105

Null object pattern in Java API?

I am trying find an example in the Java API where the Null Object pattern is being used ?

I have seen this statement on stackoverflow that ComponentAdapter, FocusAdapter, KeyAdapter, MouseAdapter are actually Null Objects:

Adapter pattern: InputStreamReader and OutputStreamWriter NOTE: ContainerAdapter, ComponentAdapter, FocusAdapter, KeyAdapter, MouseAdapter are not adapters; they are actually Null Objects. Poor naming choice by Sun.

I am not sure how ?

Upvotes: 4

Views: 258

Answers (2)

davidxxx
davidxxx

Reputation: 131556

IHMO ComponentAdapter, KeyAdapter and all these AWT classes don't match to the null object pattern intention :

In most object-oriented languages, such as Java or C#, references may be null. These references need to be checked to ensure they are not null before invoking any methods, because methods typically cannot be invoked on null references.

But these match to its description :

Instead of using a null reference to convey absence of an object (for instance, a non-existent customer), one uses an object which implements the expected interface, but whose method body is empty. The advantage of this approach over a working default implementation is that a null object is very predictable and has no side effects: it does nothing.

Matching to a description/implementation is finally just an implementation detail. For example mocks, stubs and dummy objects match also to this description. Should we consider it as Null objects ? I don't think so.

These AWT classes look to be convenient implementations to spare some mandatory implementations with empty body inside.
For example, a JFrame subclass could implement only methods of KeyListener that needs with a KeyAdapter : 

public class FooFrame extends JFrame {

    public FooFrame(){

        addKeyListener(new KeyAdapter() {
            @Override
            public void keyTyped(KeyEvent e) {
                if (e.getKeyCode()== KeyEvent.VK_ENTER){
                    // do something
                }
            }
        });
    }
}

But with KeyListener it should implement all of them (with an empty body for them that we will not use) :

addKeyListener(new KeyListener() {
    @Override
    public void keyTyped(KeyEvent e) {
        if (e.getKeyCode()== KeyEvent.VK_ENTER){
            // do something
        }
    }
    @Override
    public void keyPressed(KeyEvent e) {
    }

    @Override
    public void keyReleased(KeyEvent e) {
    }
});

The important thing here is that using or not these "adapter" classes will not protect your code more against NullPointerException. So definitively no, these don't look like Null objects.

So do we have null object pattern in the JDK ? Maybe, but anyway not sure and not common.

Source : https://en.wikipedia.org/wiki/Null_object_pattern

Edit for existing examples

For example, some aspects such as caching or security have "real" implementations in production environments while in local or integration environments you may want not to use these implementations because expensive or complex in terms of overhead or setup.
In this case, you generally use a no-op implementation rather than assigning a null reference for them that would force you to check the no nullity of the at each time that these fields are used such as :

if (cacheManager != null){
   // use cache manager
}

For example, Spring provides org.springframework.cache.support.NoOpCacheManager for no-op CacheManager implementations.

As a side note, you can notice that ComponentAdapter, KeyAdapter, and so for... are also no-op implementations (same description as NoOpCacheManager) but their intention is difference : these AWT classes prevent useless code / boiler plate code while the second prevents the no nullity checks.

Upvotes: 3

Andrew
Andrew

Reputation: 49656

One of the characteristics of a null object is that it does nothing and its methods are empty. All the classes you mentioned possess this property, so you can identify them as examples of the null object pattern.

The naming choice isn't poor. They all are adapters, in the first place.

A strong counter-argument could be that they are abstract which makes them impossible to be initialised.

Even if we know a simple workaround 

FocusAdapter adapter = new FocusAdapter() {};

Upvotes: 1

Related Questions