Lecture thumbnail 0:00 / 0:00 So one question which we haven’t really addressed, but we should address is if you want a singleton,
why not just make the whole thing static?
Because you can make a static class with a bunch of static members.
Now, it is certainly possible.
However, a static class with static members is terrible because it doesn’t even have a constructor.
So whenever you actually use this class, you end up referring to it by its name.
And so you cannot use things like dependency injection.
So we have that same problem that we had already looked at in terms of testability.
So there is a variation on the singleton pattern, which is called the mono state pattern, which also
tries to use static members in a really bizarre way.
So let me show you how this works.
Let’s suppose that I make a class called CEO.
Now let’s suppose that in our company there can only be one CEO at any given time.
So we want to prevent people from actually making more than one CEO.
On the other hand, let’s suppose that we actually want to allow people to call the constructor and
instantiate the object.
So what can we do?
Well, we can actually have the state of the CEO being static, but being exposed in a non static way,
and that is the mono state pattern.
So it’s really weird.
Let me show you how it would work.
So essentially we might have something like private static string name and then private static int age
for example.
So these are the actual properties of the CEO and then you make the properties around these fields,
but you make them non-static.
So if we make a property called name, let me try this again.
If you make a property called name, you remove the static keyword and the same goes for the age property.
Once again you generate it, but then you remove the static keyword.
And then what you can do is you can, for example, implement formatting members.
So we can generate a nice two string implementation for the CEO and then we can start using it.
So the client of this pattern and this is the classic mono state pattern would be able to instantiate
the CEO so you can in fact make a CEO, var CEO equals new CEO like so and you can set the properties.
So you can say CEO name equals Adam Smith and for example, CEO dot age equals 55.
But then you can also make a new CEO.
So you can make another CEO, let’s call it CEO two equals new CEO.
And even though these are separate objects, they have their own separate allocation.
They both refer to the same data because the properties that they expose actually map to static fields.
So as a result, having made CEO two, I can now output the data about CEO two.
So Writeline CEO two And if I actually execute this well, you can already guess what is actually going
to happen because essentially we are referring to that same data regardless of how many CEO objects
we make.
So CEO two is also Adams with with age 55.
Now, this is a particularly bizarre approach to the singleton because on the one hand, it works to
a certain degree and it works even though you allow people to call the constructor.
So typically, our singleton approach has been to prevent people from calling constructors.
But in this case, we’re doing the opposite.
We’re saying, Well, it’s okay, you can call as many constructors as you want, you can make as many
objects as you want, but whenever you actually use the properties of those objects and the properties
are non static themselves, you can see that name and age.
I’ve deliberately removed the static keyword.
They still map in terms of the fields, in terms of the actual state, they still map to static fields
and as a result they all share the same data.
So this is the gist of the mono state pattern.
Play Play Play Play Stop Play Play Start Play information alert