Question

I’m having trouble wrapping my head around state-based functionality for an invoicing system we are currently building. The system will support calculation, manual approval, printing, and archiving of invoices.

At first I thought we should use the State Pattern to model this. An invoice would be the context, which delegates printing, archiving, etc. to its currently assigned state.

But this is obviously a bad idea, because the different states (created, approved, printed, archived) should not support the same operations. E.g., you shouldn’t be able to print an invoice, which hasn’t been approved before. Throwing exceptions for unsupported operations would be a violation of LSP. I found a general description of this problem here.

Does anybody have an idea, how to implement this appropriately?

---

PS: I’m aware that this might sound like some lame-ass homework assignment, but it’s not; I need this for a real world system.

Answer 1

You’re basically creating a workflow of application states, where at each state the available operations on an invoice change. The state pattern doesn’t seem appropriate, but you can still use it if you also create some operations like boolean canPrint() that would have to be used before calling print(). print() would have a contract that allows throwing exceptions if canPrint() returns false. This way, subclasses wouldn’t break that contract. Another option is to have a boolean tryPrint(), that will only print if it can, and return whether it printed.

But, if the states support mostly non-overlapping operations, then maybe the state pattern is not the solution. Take a step back and look for better ways, without trying to fit a specific pattern to your problem. One way is to create a separate class with the necessary operations for each “state”: like CreatedInvoice, ApprovedInvoice, etc. These classes would only have the operations they support.