The state button issues, whenever you want to change the state of your object, but you don't want
to have these changes in the underlying class.
It is a very good choice for factoring in classes where you use many, if else, statements.
Imagine having a product in a store, the product can take multiple states, the product can be for
sale or it can be sold or even borrowed.
With this backing, you delegate the state changes to the respective state objects.
So you won't need to rely on many, if any, statements to capture the changes in the state of the initial
object.
Looking at the U.N. diagram, the context object would be the product.
The state interface will contain the contract for the state implementation.
The context clause will delegate its state to the concrete state implementations.
You can have many implementations, not just you, but for simplicity.
The standard diagram for this matter includes only two.
Let's see how this pattern can be implemented.
Endako.