I was thinking in the common example orders, that can be in different statates. From create to pending to accept, accepted, sent... and so on.

But the order has data too, for example the client, the address to deliver, coments and another information that can be modified depending on the state. For example, the address can be change before it is sent, the comments shouldn't be modified since the order is prepared and so on. For that, I would bave behaviors like SetAddress(), SetComments()... and so on.

Also I can add items to the order, but only when it is in created state, or initial state. So it depends on the state too.

I can considerate the state pattern to control which actions can I do depending on the state. For that, for each state class, I have to implement the method SetAddress(), SetComments(), AddItem(), StateToPrepared(), StateToSent(), StateTodelivered()...

So at the end, the order will delegate all the behaviour to the state classes, and state classes would be so big because it would have all the ligic of the order.

So this makes me to think that really I don't understand the state pattern, so would like to clear this doubts.


1 Answer 1


The state pattern dictates what an object does, not what an object can do. It's a subtle distinction. An order can always AddItem(item), however depending on the state different things could happen.

  • If the order is open it adds the item.
  • If the order is open and the item is already in the order it could return an error or increment the quantity of the item.
  • If the order is shipping then it could return an error or create a new order with the item.

Another example would be a Process() method.

  • When the order is open, it calculates a total and changes the order to Pending Payment.
  • When the order is pending payment it confirms the payment was successful and changes the order to Fulfillment.
  • When the order is Fulfilment it confirms all items are packaged, finalizes hipping info, and changes the object to Shipping.
  • When the order is shipping it changes the order to complete.
  • Then, is the context (the order) who determinates the conditions to add the item? So AddItem wouldn't belong to the state classes because AddItem() is doing always in the same way? And the state pattern it is when the same action is doing in different way depending on the state? Oct 5, 2022 at 18:45
  • Well, I was thiking and perhaps AddItem is not always possible to do. If the order is closed, instead of return an error, just it could tell it is not possible because of the state. I could have a method for validation if it is possible to add items or not. And perhaps AddItem depends on more conditions, like for example, don't allow to have two lines of the same item. This doesn't depen on the state. So I don't see if AddItem through the concrete state class of the state pattern it would be the best place. Oct 6, 2022 at 10:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.