1

I'm trying to figure out the best option to mark a database entity that could be closed manually or automatically. This entity already have a status that accepts OPEN or CANCELED.

Now, I would like to "close", but the close action can be manually or automatically, and I will need this information in the future to know how this entity was closed.

So, I think I had two options:

  1. Create two different status: CLOSE_MANUALLY and CLOSE_AUTOMATICALLY.
  2. Create one status CLOSE and create a boolean flag close_automatically

Is there some obvious option between this two? Is there another option?

  • There could be more causes? Closed remotely? Closed because it was struck by a thunderbolt? IMO, the cause is contextual. It enrichs the state, but it's not an state by his own. – Laiv Feb 8 '18 at 20:01
4

Go with a single state 'Closed' but also record actions that are taken against the record.

This covers you for situations where say the record is closed automatically, reopened and closed manually.

Its better to check the history of actions rather than try to have states for each possible action , or set of actions that would otherwise result in the same state

  • Thanks! This is better, for sure. But the application is not able to reopen or have another way to close the entity. Do you think that approach is still better? My history actions will be always with one single register in your solution. – Dherik Feb 9 '18 at 11:05
  • In my experience, once you hit this issue for the first time, its just the tip of the iceberg and you will find a million other things that also use it – Ewan Feb 9 '18 at 12:17
1

I would go for the first option (making a separate state for each case). This way, your status is a simple state machine. Even just looking at the list of available states gives me a pretty good idea of the possible transitions.

If parts of your code need to check whether the DB was closed regardless of the method (automatic/manual), you should provide a function for that. Don't make your clients check both states every time.

Of course OPEN/CANCELED/CLOSED is even simpler, but now you have an additional flag that only has meaning in one specific state.

A possible alternative is the state pattern, which would allow you to also encapsulate the state-dependent behavior. In addition you could have methods like WasClosedAutomatically() which would return false for all states except one. However, most likely this is overkill for you.

  • The overkill then comes when you have to filter by CLOSED, independently from the cause. You have to start to filter by a set of states that basically means the same. CLOSED. – Laiv Feb 8 '18 at 20:06
  • @Laiv that's why I suggested to have an IsClosed() method (or property/whatever) that checks for both. – doubleYou Feb 8 '18 at 20:37
  • That's the same as checking state+flag. Isn't it? – Laiv Feb 8 '18 at 20:39
  • @Laiv either way, you'll have at least one 'composite' state that requires 2 checks. What I don't like is the additional flag variable that has no meaning in 2/3 of the states. – doubleYou Feb 9 '18 at 17:05
  • That's why Ewan suggested a history of events – Laiv Feb 9 '18 at 17:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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