Back in my delegate decorator article, I mentioned some weaknesses of the delegate pattern as a substitute to inheritance. The decorator solved one of those problems, but the other is still a problem. The problem comes when using something akin to the template pattern.
\n
\n
\n
\n
\n
\n <\/p>\n
For example, if you have this class:<\/p>\n
class TemplateUser:\r\n def intermediate_step(self):\r\n ...\r\n\r\n def multi_step_operation(self):\r\n ...\r\n self.intermediate_step()\r\n ...<\/pre>\nThen you try to create a delegating class like this:<\/p>\n
class TemplateUserDelegator:\r\n def __init__(self, delegate):\r\n self.delegate = delegate\r\n\r\n def intermediate_step(self):\r\n ...\r\n self.delegate.intermediate_step()\r\n ...\r\n\r\n def multi_step_operation(self):\r\n ...\r\n self.delegate.multi_step_operation()\r\n ...<\/pre>\nUnfortunately, when you run the line:<\/p>\n
TemplateUserDelegator(TemplateUser()).multi_step_operation()<\/pre>\n
TemplateUserDelegator<\/code>\u2018s wrapper ofintermediate_step()<\/code> doesn\u2019t get called. Why is that? Because you\u2019re askingdelegate<\/code> to runmulti_step_operation()<\/code>, which doesn\u2019t haveTemplateUserDelegator<\/code>\u2018s version ofintermediate_step()<\/code> within.<\/p>\nAttempts At Solutions<\/b><\/h2>\n
We could explicitly call the delegator\u2019s
intermediate_step()<\/code> within itsmulti_step_operation()<\/code>, but that would result in callingdelegate<\/code>\u2018sintermediate_step()<\/code> twice; once within the wrapped version and once withindelegate<\/code>\u2018smulti_step_operation()<\/code>. There are some few cases where that could work.<\/p>\nWhat if
TemplateUserDelegator<\/code>\u2018sintermediate_step()<\/code> only did its own work without delegating todelegate<\/code>\u2018s? Again, sometimes, that might work, but not usually. Often, it\u2019s not quite the case of the pure template pattern, where the intermediate steps are \u201cprotected\u201d. There are many times where the \u201cintermediate step\u201d can also be called on its own as a full step.<\/p>\nFor example, for a collection, it could have an
add()<\/code> method that adds one item to the collection and anadd_all()<\/code> method that adds many items to the collection at once. Likely, theadd_all()<\/code> method makes a call toadd()<\/code> for each item it\u2019s attempting to add. If you were to extend that collection with delegation and that extension does a transformation action to the item being added. What do you do then? About the only solution then is to completely reimplementadd_all()<\/code> without delegating. That\u2019s not very DRY, though, so we could really use something different.<\/p>\nSolution<\/b><\/h2>\n
The solution is to switch from the template pattern to the strategy pattern.<\/p>\n
So we\u2019d rewrite
TemplateUser<\/code> like this instead.<\/p>\nclass TemplateUser:\r\n def __init__(self, strategy):\r\n self.strategy = strategy\r\n\r\n def intermediate_step(self):\r\n self.strategy.intermediate_step(self)\r\n\r\n def multi_step_operation(self):\r\n ...\r\n self.intermediate_step()\r\n ...<\/pre>\nTechnically, since this strategy type only requires one method, it should be a callable instead and just called via
self.strategy()<\/code>.<\/p>\nNote that
self<\/code> is also passed into the strategy method. This is to give it access toTemplateUser<\/code>\u2018s fields if need be. This should actually be avoided in most cases. Most decoration\/delegation is done only to the input parameters and return values. Giving access to fields increases coupling. It is simply shown for the sake of being an example possibility.<\/p>\nWhat if you can\u2019t make changes to
TemplateUser<\/code>? What then? Well, then you\u2019ll actually have to use a little bit of inheritance to enable the use of composition.<\/p>\nclass DelegatableTemplateUser(TemplateUser):\r\n def __init__(self, strategy):\r\n super().__init__(self)\r\n self.strategy = strategy\r\n\r\n def intermediate_step(self):\r\n self.strategy.intermediate_step(super().intermediate_step)\r\n\r\n def multi_step_operation(self):\r\n self.strategy.multi_step_operation(super().multi_step_operation)<\/pre>\nYou use the new subclass to delegate to the strategy objects you provide, which have all the steps methods with the same name and same set of parameters, except it also needs a parameter to accept the base method as well. This allows the strategy to call the delegated-to method when it needs to, or skip calling it, if it prefers (which is not a good idea, in most cases).<\/p>\n
It can also take in
self<\/code> if it needs to, which is not shown in this example. This has the same warnings as it did with the previous solution.<\/p>\nNote: do not accidentally call
super()<\/code>\u2018s methods when passing them into the strategy calls.<\/p>\nOutro<\/b><\/h2>\n
So that\u2019s how you can design the \u201ctemplate pattern\u201d to be used by the delegation pattern. The second solution can be kind of a pain, but if it needs to be done, then it\u2019s worth it.<\/p>\n
To prevent some of the negative comments I\u2019m going to get: yes, I know inheritance is good and useful at times, but the experts say to prefer composition over inheritance, and from what I\u2019ve seen, I\u2019m highly inclined to do that. I\u2019m trying to help people get out of ruts where it looks like they CAN\u2019T do the composition they want.<\/p>\n
On another note, I won\u2019t be posting for a little while now. I\u2019m going to be working on writing up a (hopefully) comprehensive guide to python descriptors. Sadly, it won\u2019t be posted right away either. I\u2019m looking to have it be a paid publication. When it\u2019s available, I\u2019ll let you guys know.<\/p>\n
\n