I have a system where lot of messages come and go over network, each message to be sent or received goes through several states, state change occurs based on external events for example if the linked contents of message are downloaded then it changes the state, if its replied then it changes state etc.

A message received has different events and set of states than a message sent . The entire statemachine has been modeled as a class and message as a member to the state machine. Message here is just a placeholder to hold the state / Model you can say.

My view here is message should hold the state ofcourse but it sole should be responsible to decide the next state , based on trigger it receives rather than another object such as StateMachine object.

Need to know if what I am thinking is technically correct from OOD point of view.

  • 1
    You question is a bit confusing as typically the state machine might receive messages, but the messages themselves are not state machines, in the sense that they are usually immutable. – Frank Hileman Aug 9 '17 at 21:29
  • You are confusing message as an object and messages we pass to objects using methods – vishal dharankar Aug 10 '17 at 6:03
  • That is why your question is confusing. The transitions on a state diagram are typically triggered by something called a message or an event. – Frank Hileman Aug 10 '17 at 22:19
  • @FrankHileman I have clearly stated that I have a system where lots of messages come and go over network , I don't know how it's confusing , never mind the answer is already there – vishal dharankar Aug 11 '17 at 2:38
  • I recommend to use a prefix for your IM class, perhaps Instant or User. – Frank Hileman Aug 11 '17 at 22:59

each message to be sent or received goes through several states

If each message has its own state, then yes, it should hold the state machine in order to react to its environment according to it's current state.

Using the GoF terminology:

  • Your message would be the Context
  • The message would own an abstract State by composition
  • State dependent operations would be forwarded by the Context to the concrete active state

The state design pattern lets open who defines the state transition. Typically it could be the Context (i.e. Message) involving a state machine, but a more flexible approach envisaged in GoF is to defer this responsibility to the state itself.

However, if you have a huge number of active messages that share some states, it could be an overhead to have each instantiate its own state machine. You could in this case consider combining the state design pattern with the flyweight pattern.

  • So I assume holding a sate of message inside message as a value and then assigning responsibility to change the state of this message to other class called StateMachine is a bad design. – vishal dharankar Aug 9 '17 at 19:26

I agree with @FrankHileman's comment on terminology of messages as having state as being confusing and a rather non-standard usage of the concept of messages.

Messages, almost by definition, are immutable and pass between two or more of some kind of (mutable) entity, such as actors.

It would be the actors that follow state machines, given messages, in order to determine what to do next. Each actor might have their own (different) state machine. The number of actors has to do with your domain.

While sometimes we might be able to model all the states of all of the actors in one model there is no requirement to do so, and it would likely be simpler to have independent state machines associated with different actors.

I would recommend associating with each actor only the states and state machine that each in turn needs, rather than having a global StateMachine object.

Generally speaking it is better to distribute responsibilities among the responsible parties (i.e. the actors) rather than collect one aspect or cross cutting concern of all responsibilities (e.g. the states/state machine) into one global place/entity. This tends to reduce coupling by way of supporting Single Responsibility Principle (SRP); we want domain entities to have one domain responsibility.

Whereas centralization tends to increase coupling, making it harder to make independent modifications, independence being key goal in support of long-term maintenance.

That's not to say that centralization of cross cutting concerns doesn't have some advantages, but it comes at cost of maintenance and sometimes also increases other complexities by introducing an additional implementation-oriented, rather than domain-oriented, entity.

Introducing a separate entity having centralized responsibility for a functional concern that cross cuts several actors supports SRP in some very indirect sense; however, we would be speaking of SRP regarding a lower-level responsibility, an internal implementation responsibility, rather than a domain-level responsibility. I would consider that weaker design with stronger coupling.

  • You got it wrong I am talking about message as entity or object not a message which we pass to objects , this message is an IM message – vishal dharankar Aug 10 '17 at 6:02

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.