Lecture thumbnail 0:00 / 1:57 We’re now going to discuss one of the design patterns, which are not part of the Gang of Four design
patterns, but it is a design pattern which is fairly popular and also well known by many people, and
it also shows up quite a bit in development.
So it’s actually a behavioral design pattern with no behavior at all.
So some people actually classify it as a structural design pattern.
So the null object is all about solving a particular problem.
So the problem is this when you have a component, A which uses component B, there’s typically an assumption
that the component B, which is used in component A is not set to null.
So you, for example, if you’re using dependency injection, you’re going to inject B, you’re not
going to inject B question mark typically or some kind of special option of B, you’re going to be injecting
B and whenever you use an instance of B, you typically don’t go around sprinkling null checks all over
the case.
The only place in the net framework where you sprinkle null checks is events.
If you have an event, yes, you use the question mark dot operator all over the place because if there
are no subscriptions to the event, then the event is null and you don’t want to call something on that
event.
But apart from that, nobody really does it.
So the question is, well, given that there is no option of telling A not to use an instance of B,
so if A has hardcoded the use of an instance of B inside itself, then we have a problem.
So what we do, if we need to supply a B, which does absolutely nothing, is we build a special class,
we build a no op non-functioning inheritor of B, and that’s what we pass into A and we hope that it
works.
So the null object design pattern is all about building an object which conforms to the required interface,
satisfies some sort of dependency requirement, for example, but does absolutely nothing at all.
Stop Play Play Play Start Play information alert