Lecture thumbnail 0:00 / 0:00 So there’s another thing that I wanted to show with respect to the null object, the kind of approach
which might be a bit silly in terms of encapsulation, but it may or may not work for you.
So one problem with the interface if you use an interface is that you have to have a class somewhere
which implements this interface.
So you make a class called Null Log.
And we’ve done this before on many occasions, which implements I log and which just does absolutely
nothing inside the methods.
You can also make the class sealed, but this doesn’t prevent people from creating additional instances
of this class regardless.
So even though it’s sealed, people can create instances of null log.
So then what happens is you can try to protect this class from being instantiated more than once.
And this is the typical singleton pattern.
So this is where you would create a constructor that is private and then you would maybe have some sort
of private, static, lazy, null log, blah blah, blah instance.
And then you would expose it somehow.
So you could certainly expose it as null log, or you could do something like the following.
You could say public static, let’s say instance, and that would be of type, let’s say log.
So I log instance would return whatever this lowercase instance would be.
So you would return the instance of value like this.
And obviously I am neglecting to actually instantiate the whole thing right here.
This is where you would do this.
So this is one approach and it might work in the sense that it will in fact work.
But still it’s a bit annoying because you are kind of exposing the existence of the null log class altogether.
And one of the things we often do when it comes to encapsulation is we don’t just hide behind an interface
like we do here, but we try to do is we try to never give the user the actual class to begin with,
meaning they don’t interact with it.
So the question is how can you expose an I log without having a user interacting with a separate class?
And in the latest versions of the C programming language, you can in fact get this kind of behavior,
surprisingly enough, by sticking the entire behavior inside the interface itself.
So that’s a really strange approach to solving the problem.
But we’re going to take a look at it regardless.
So essentially what you can do is you can put classes right inside interfaces.
So inside the I log interface, we can have a private sealed class, private sealed class null log,
which implements I log and this is where you would implement this in a typical singleton approach.
So you would have a private constructor and you would also have some sort of private instance variable,
maybe static, lazy, null log called instance, which you would instantiate as a simply a new instantiation
of null log.
So you would make it lazy like so, and then you could expose it of course in the typical way.
So you would have a public public static log instance which would return instance dot value.
So this would make it kind of lazy instantiation And what you can do now is jumping back into the I
log interface.
What you can do is you can have a property, you can have a static property inside the interface.
So public static log null goes to null log dot instance.
So this is how you would expose it.
And surprisingly enough, this works in the sense that you can now type the following.
You can type log now and this would actually give you the requisite instance.
Now the advantage of this approach over the previous approach is that the class is completely concealed
from the client, so the client doesn’t need to know or care that this interface has this class inside
it because it’s not actually exposed in any public way.
We simply expose an I log and this entire implementation is a very well concealed from the client.
On the other hand, there is a downside to this because we are violating one of the core principles
of development, which is the principle of least surprise.
You see most developers when they look at an interface, the last thing they expect inside an interface
is a static property in that interface.
So nobody will be looking for that particular property.
And as a result, even though you have this very useful singleton object that will be returned whenever
you call log.
Now, people might not actually be able to find it simply because they don’t expect an interface to
contain a static property.
So that is something to watch out for.
But I just wanted to let you know that this approach is also available if you want to take advantage
of it and provided that you consume the code yourself, you could be completely fine with this kind
of approach because you know that the member is there, so you would simply access it when you need
to.
Unfortunately, when it comes to exposing this as a public API, well, I would exercise a bit of caution
because it’s definitely.
Not as intuitive as some of the other approaches.
Play Play Stop Play Start Play information alert