The mono stage design pattern is a particularly curious variation on the singleton design pattern so
we're going to take a look at it.
And the idea is rather simple let's suppose that you want to have let's say you want to have a class
called printer.
So what you do is you make the printer appear to be just an ordering class.
No Singleton implementation anywhere except that all of the actual data storage for the printer is actually
static storage.
So let me show you how this works.
Let's suppose the printer has an ID which you want to be.
You want the whole thing to be a singleton so you make the storage static and then you expose the storage
so you have functions called get ID which would return the ID and you would have maybe a function called
Set id
where you would set the ID all asleep.
So you would say ID equals value.
There we go.
So what does this mean.
Well for the consumer of the money the state Design Patterns are going to be working with the ordinary
time.
Theyre going to be making instances of it so theyre going to be saying printer P and then they're going
to be saying well printer don't get ID.
Maybe they'll be saving it somewhere or something to that effect.
But behind the scenes what's happening with the state is all of this storage is actually going into
a static member.
So essentially it doesn't really matter how many instances you make if you make another printer up to
both of these printers they actually work working with the same data even though it feels like they're
using instance methods and therefore they're separate instances.
So there are lots of reasons why this is a bad idea.
I mean if you think about inheritance from for example inheritance is going to be really bad because
you effectively have this thing as non inheritable mandar.
Or are you really inheriting here he is the getter and the center you cannot inherit a static field
and there are lots of issues besides that.
So it's a really inflexible and really bizarre solution.
But I think the worst issue with state design pattern is that the client isn't really informed about
the fact that there's a de facto Singleton So you're going to have people who are going to be making
many instances of it and they're going to be setting the fields and then they will be getting really
strange results from those fields because whatever the latest set operation is it basically sets every
single instance because there's really only one storage location the static location where the data
is kept.
So the moona state is a particularly bad idea but I'm just I just wanted to present it here for the
sake of completeness because it is a viable solution to the single problem but it is a solution which
brings a lot of drawbacks so I wouldn't recommend actually using it in production.
But you know on the off chance that you might need it.
Well here is.