Re: [PEPr] Comment on Tools and Utilities::ScriptReorganizer

On Wed, 18 May 2005 11:06:28 +0200, Vincent Lascaux <vincent.lascaux@centraliens.net> wrote:

OK, that's where I don't follow you... Why is RenameVariables a decorator rather than a strategy? Pack is also an additionnal functionnality (remove the unnecessary whitespaces), and it is optional (I can use quiet if I don't want to remove those whitespaces). I'm not sure what you mean about the "core reorganization of the source". I agree 100% that the decorator design allows that kind of thing, and that's why I proposed to use this design for strategies (or even to merge them since I'm still not sure about their differences).

A decorator lets you change the skin of an object; a strategy lets you change the guts. The strategies Pack, Quiet and Route are just different variation of the same core responsibility - the mandatory behavior as I have defined it (reduction of the file's size). The decorators AddHeader, AddFooter and Pharize are responsibilities that can be withdrawn without affecting the object (and its responsibility) in discussion. Let me tell you where I come from, to clear up possible misunderstandings: initially I only had the script/library type and the pack strategy (implemented directly in the type classes) in place. I was happy and everything was fine. Starting to think about PEPr I realized that the hack (not even unit tested) was not good enough for being accepted. So I kicked off with looking at the problem domain more in depth and applied amongst others the Principle of Designing from Context (create the big picture before designing the details) as well as the Open-Closed Principle (design the software so that one can extend its capabilities without changing it). Taking into account that encapsulation should be thought of as "any kind of hiding" and not only as "hiding of data" and considering what I wanted to be able to change (the strategies as well as the additional functionalities) without redesign, I came up with the design proposed. You should not be surprised to hear that I have explored an alternative solution with filters too. I had the script/library object accepting implementations of filter for the reorganization process. After a very short time I scrapped this idea, for it was cumbersome to use, showing a high coupling between the existing classes and resembling IMHO to much of a procedural approach. ANN: That's the reason why I see RenameVariables as a decorator and not as a strategy. Depending on how it would be implemented as well as how the source to reorganize is structured, it could eventually even increase the files' size and thus not comply with the ScriptReorganizer's "contract".