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

On Mon, 16 May 2005 15:46:54 +0200, Vincent Lascaux <vincent.lascaux@centraliens.net> wrote:

Comment: I find the general idea good...

Thanks!

I don't think Type is a good name, Document would probably be better (if I understand what it does right: storing the document (script or library) that will be transformed by a strategy).

<Type>, as, without any doubts, you will have seen in the source, is the "abstract concept" of what _has_to_be_created_ and only by chance holds the "original document" to be processed. It's more the notion of what the output will be: "document" of <Type> script or of <Type> library, two different implementations of said concept. What about the name <Code>, which, IMHO, does reflect even better what is being looked at - with "Document" I do associate more something to deal with a word processor, a grafical tool etc. Just a thought. However, having said this, I have no problems with changing the name of the class, if there are more fellow PEAR developers who are of the same opinion as Vincent.

About the design itself, I think that the decorators should be strategies (since they just modify the script, exactly like strategies do), and I don't think the Type (or Document) should hold the strategies: strategies should be applied on documents, something like $strategy->transform($document)

I do follow you on this, but the reasoning behind the separation of stratagies and decorators is very simple: - Strategies are _mandatory_, i.e. it does not make sense to create a "Document" object without knowing in advance, which <Strategy> to apply (remember, that the context of ScriptReorganizer is the deployment of code and not a dynamic web application - it's just a work horse package) ... it simply can't be missed by chance and it's anchored with the instantiation of the "Document". - <Decorator>s can be used, but must not be applied (in contrast to the <Strategy>), which is slightly a different notion. You create a <Script> or a <Library> together with the <Strategy> and whenever you feel the need, you use <Decorator>s to add dynamically further attributes/qualities. To have a choice here in this respect is more appropriate than with strategies, at least in my opinion. What are the feelings of the other PEAR developers in this respect?