Introduce Null Object
From CSSEMediaWiki
(Difference between revisions)
m (New page: ''Summarised from Refactoring'' Martin Fowler 1999 == Motivation == You have repeated checks for a null value For example your code my look like: if (customer == null) plan = Bill...) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Michal Connole) |
||
| (12 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
| + | [[Category:Design Patterns]] | ||
| + | [[Category:Behavioural Patterns]] | ||
''Summarised from Refactoring'' [[Martin Fowler 1999]] | ''Summarised from Refactoring'' [[Martin Fowler 1999]] | ||
| − | + | Adds an object that defines use and behaviour but does nothing. | |
| − | + | == Use When == | |
| − | + | If you have repeated checks for a null reference, because one can't invoke anything on a null reference. | |
| − | + | For example your code looks like: | |
| − | + | ||
| + | if (customer == null) | ||
| + | plan = BillingPlan.basic(); | ||
| + | else | ||
| + | plan = customer.getPlan(); | ||
| − | + | This pattern can also be used to act as a stub for testing if a certain feature, such as a database, is not available for testing. | |
| − | + | == Structure == | |
| − | [[Image: | + | Replace your check for a null reference with a null object |
| + | |||
| + | [[Image:Null Object.jpg]] | ||
| + | |||
| + | * Create a subclass that acts as a null version of the class. | ||
| + | * Create an isNull() method in both classes. For the superclass it should return "false", and "true" for the subclass. | ||
| + | * Find all places that can give out a null value when asked for an object of the superclass and replace them to give a null object instead. | ||
| + | * Find all places that compare a variable of the superclass type with null and replace them with a call to isNull(). | ||
| + | |||
| + | |||
| + | == Consequences == | ||
| + | |||
| + | This neglates the need to check for a null reference. | ||
| + | |||
| + | Another advantage of this approach over a working default implementation is that a null object is predictable and has no side effects: it does nothing. | ||
| + | |||
| + | ==Related Patterns== | ||
| + | It can be regarded as a special case of the [[State pattern]] and the [[Strategy Pattern]]. | ||
Latest revision as of 03:08, 25 November 2010
Summarised from Refactoring Martin Fowler 1999
Adds an object that defines use and behaviour but does nothing.
Contents |
Use When
If you have repeated checks for a null reference, because one can't invoke anything on a null reference.
For example your code looks like:
if (customer == null) plan = BillingPlan.basic(); else plan = customer.getPlan();
This pattern can also be used to act as a stub for testing if a certain feature, such as a database, is not available for testing.
Structure
Replace your check for a null reference with a null object
- Create a subclass that acts as a null version of the class.
- Create an isNull() method in both classes. For the superclass it should return "false", and "true" for the subclass.
- Find all places that can give out a null value when asked for an object of the superclass and replace them to give a null object instead.
- Find all places that compare a variable of the superclass type with null and replace them with a call to isNull().
Consequences
This neglates the need to check for a null reference.
Another advantage of this approach over a working default implementation is that a null object is predictable and has no side effects: it does nothing.
Related Patterns
It can be regarded as a special case of the State pattern and the Strategy Pattern.
