0

I am using state pattern on 28 states in my application, the states are for membership cards that has 7 major states, there are 4 boolean attributes for the membership card that actually affects the its behavoir so i have decided to embed them with states, that's how it multiplied to 28 states.

the problem now is with states class naming, it is getting crazing, i am ending up with class state named like this Membership-UnderCreation-Printed-Linked-Premium-Frozen ----- i have hyphened different attributes to make it clear.

is it ok for state class names to be like this?! what should i do for best practice?

jaco0646
  • 15,303
  • 7
  • 59
  • 83
Sisyphus
  • 900
  • 12
  • 32
  • If you have 4 boolean attributes, should that not translate to 16 states on its own ? Probably you mean only one of the attributes can be set at a time, if that is the case, then these attributes are not independent. – shr Sep 10 '13 at 04:22

2 Answers2

0

Perhaps you are pushing it too far. I dont think your current approach is maintainable and depending on how all this will evolve, it could lead to an explosion of different states.

I have a few ideas on how you could tackle the problem. You could implement the 7 main states using the state pattern and use flags to track the other conditions, so within each states you could write conditionnal statements based on these. The code within functions would get slighlty more complex, however I believe it will still be more maintainable.

I do not have much information about your state transitions and everything, but another idea would be to have a single state class from which you can create anonymous subclasses by passing in a collection of conditions that needs to be met to activate the state.

Then, you do not have to name any of your states, you simply have to keep them in a collection and when any properties of the main object changes that might cause a state change, you loop over the state collection and your will find your new state by comparing the object properties with the state conditions.

Note that you could also use a HashMap to store the states and create a hash from all conditions to get a unique key. That would make state lookups faster than looping over all of them to find the next state.

plalx
  • 42,889
  • 6
  • 74
  • 90
  • i have thought of this first solution, but didnt want to spoil the pattern that's why i am striving to get it completely right :( – Sisyphus Sep 07 '13 at 21:02
  • Well, sometimes it just doesn't fit. The way you want to implement it is simply not maintainable. Have you tought about my second solution (using anonymous classes)? That would definitely be better than create a concrete class for every permutations. – plalx Sep 07 '13 at 21:12
  • i am not sure i get your second solution, may be because i dont know much about anonymous classes, i am using c# btw, does it support anonymous classes? – Sisyphus Sep 07 '13 at 21:27
  • @user2080257, Hum I checked and there isin't anything like anonymous classes in C#, however you can have a look at http://stackoverflow.com/questions/4770180/anonymous-inner-classes-in-c-sharp – plalx Sep 08 '13 at 03:10
0

As plalx commented, as it stands, the design is not easy to maintain. As plalx suggests, you should have only 7 main states.

For the other 4 attributes, one option is to use the decorator design pattern. Each of the 4 attributes could be designed as 4 decorator classes. Based on which attribute is set, the corresponding decorator object will wrap the original object. The decorator can then intercept calls from clients and modify the behavior based on the attribute for that decorator.

shr
  • 875
  • 10
  • 20
  • i have checked the decorator pattern, but it looks like for it to be useable, a method in the extending class has to contain the complete behavior of its base method in the concrete class as part of it, which is not the case here, i am talking about a completely different behavior for each method most of the time. am i getting it right? – Sisyphus Sep 10 '13 at 08:22
  • I do not think the decorator pattern would work well here, since it's the combination of multiple states that defines the behaviour, which means that a decorator would need to be aware of other's to define it's own behaviour. – plalx Sep 10 '13 at 12:41
  • @user2080257 You are right. If every method is going to be different, then decorator pattern is not a good fit. If most of the methods are different for each of the 23 states, then there is very little you can do to improve upon your current design. – shr Sep 11 '13 at 04:02