The Token Anti-pattern
Over the last several years or so, I have observed something that I refer to as "The Token Anti-pattern". I have seen this pattern rear its ugly head as a way of passing parameters from one class to the next. The parameters are neatly wrapped up as properties of a class.
In the worst case that I've seen the Token had about 20 properties that were not cohesive, making the token class itself non-cohesive. It was a scenario where the process was basically a work flow. The workflow stepped it's way through many steps. Many of the steps branched out to different paths, calling out other objects. The token was passed to these other objects. The different paths required different pieces of information as preconditions. These pieces of data were attached to the "Token" along the way. The token for one path would have property1, property2 filled but property3 null. Whereas for a different path property1 would be null and property2 and property3 would be filled with data, and so on.
In that particular case the process worked initially. Later in the project some bugs were discovered and it was a nightmare for anyone to even try to follow this process. It was unpredictable what effect a change to the token in one part of the process would have on another part of the process. Fixes to this code would almost always result in further rework.
Eventually for a later release of the application, this process was redesigned and reworked. The "Token" was eliminated. The process was redesigned as true workflow. The calls to many of the other services were replaced with command interfaces. The explicit parameters that were necessary for these commands were passed instead of passing an entire "Token" class.
I can proudly say, being part of the redesign team, that this new code has produced very few defects. Even when a defect is found, it is easily fixed because the code is more loosely coupled. The token had single-handedly managed to couple every step in the process.
If you ever find yourself passing an object with more properties than necessary for the consumer class, you may just have and evil token on your hands. If in the second class you pass this object to yet a third class, then you definitely have a token on your hands and you should re-think your design.
Sometimes the name alone can be smell of a token lurking in the shadows. Names like FileInfo or HeaderInfo. Really, anything with Info in the name can provide a smell. If that info object is being passed around among classes like a ball in a keep away game, then you know it is a token.
Even when the token is not being modified by the different objects that come in contact with it, it may still be poor desing. If the info object is holding more information that the other objects, need then you should potentially be sending the specific parameters to the other classes.
If you want to save yourself much grief and make your code maintainable please avoid "The Token Anti-pattern".
In the worst case that I've seen the Token had about 20 properties that were not cohesive, making the token class itself non-cohesive. It was a scenario where the process was basically a work flow. The workflow stepped it's way through many steps. Many of the steps branched out to different paths, calling out other objects. The token was passed to these other objects. The different paths required different pieces of information as preconditions. These pieces of data were attached to the "Token" along the way. The token for one path would have property1, property2 filled but property3 null. Whereas for a different path property1 would be null and property2 and property3 would be filled with data, and so on.
In that particular case the process worked initially. Later in the project some bugs were discovered and it was a nightmare for anyone to even try to follow this process. It was unpredictable what effect a change to the token in one part of the process would have on another part of the process. Fixes to this code would almost always result in further rework.
Eventually for a later release of the application, this process was redesigned and reworked. The "Token" was eliminated. The process was redesigned as true workflow. The calls to many of the other services were replaced with command interfaces. The explicit parameters that were necessary for these commands were passed instead of passing an entire "Token" class.
I can proudly say, being part of the redesign team, that this new code has produced very few defects. Even when a defect is found, it is easily fixed because the code is more loosely coupled. The token had single-handedly managed to couple every step in the process.
If you ever find yourself passing an object with more properties than necessary for the consumer class, you may just have and evil token on your hands. If in the second class you pass this object to yet a third class, then you definitely have a token on your hands and you should re-think your design.
Sometimes the name alone can be smell of a token lurking in the shadows. Names like FileInfo or HeaderInfo. Really, anything with Info in the name can provide a smell. If that info object is being passed around among classes like a ball in a keep away game, then you know it is a token.
Even when the token is not being modified by the different objects that come in contact with it, it may still be poor desing. If the info object is holding more information that the other objects, need then you should potentially be sending the specific parameters to the other classes.
If you want to save yourself much grief and make your code maintainable please avoid "The Token Anti-pattern".
Comments