Page 1 of 1
Reusable systems
Posted: Thu Dec 28, 2006 10:20 am
by alex.barylski
You've developed a DOM traverser, FSM or generic tokenizer...you now wish to keep it around as each could be handy and/or reused in future projects...
Do you:
1) Copy and paste code into new situations - tweaking as required
2) Pack it into an class and use composition/inheritence
3) Use a hooking technique ala callbacks
I realize the the question is somewhat vague, but going on the examples I gave above, how, when, where and why would you choose one approach over the other?
Cheers

Posted: Thu Dec 28, 2006 10:53 am
by feyd
Overall, I'd likely use option two. If modifications are required I may add those on via a descendant class depending on the scope and reuse abilities of the extension.
Callbacks are a possibility, but more often than not I'll be engineering classes. While callbacks are possible with them, it's a bit more awkward than having a unified interface to interact with.
Posted: Thu Dec 28, 2006 1:27 pm
by Christopher
I think you list is apples and oranges. If you do #2 then you can always do #1 and implement #3 as appropriate.
Posted: Thu Dec 28, 2006 4:30 pm
by alex.barylski
I try to avoid specifics as answers which basically repeat what I say is not what I am after, but when I'm vague I don't get answers either...
I'm not looking for answers...so much as I am unique ideas...here is my problem in detail:
Lets use a tokenizer and very simplistic parser as an example...
I've wrapped up the functionality of the PHP tokenizer inside a class but inorder to parse the tokens into something interesting (lets say a comment analyzer) in order to do this we need to iterate the list of tokens ignoring everything but TM_COMMENT???
So I've wrapped that trivial parser up in a class or maybe even a single function...a few weeks later I decide I want to extract IF statements...
More clear?
Cheers

Posted: Thu Dec 28, 2006 6:11 pm
by Christopher
Let me try avoid specifics by basically repeating that what I said is what I think you are after, but be vague to see if that gives you the answer also.
The Decorator pattern.
Posted: Thu Dec 28, 2006 8:56 pm
by Ollie Saunders
Complex: Specification pattern? Use it to specify which token you like + more.
Simple: Callback provided with token as param, that returns true on something to consider and false on something not to
Posted: Fri Dec 29, 2006 1:33 pm
by Buddha443556
An individual can get away with the simplest form of software reuse even copy and paste. Though software salvaging shouldn't be confused with software reuse. Beyond the individual, in a team environment, things get much more involved.
Posted: Fri Dec 29, 2006 1:41 pm
by alex.barylski
arborint...
The decorator sounds like exactly what I was using. It's the same technique I have applied for years in custom control development. Although MFC (Microsoft Foudation Classes) favours inheritence whereas I find JFC is geared more towards composition - I favour the latter.
Although I was unaware of the Decorator pattern (at least in definition - as I knew it existed just never read it) that isn't what I was hoping for...although I still appreciate your mentioning it as at least I now have a formal vocabularly to express the problem to others. To me, it's just always been the obvious solution to the problem of extending a control...as classes can noramlly just be extended.
My problem I guess....is that I'm always looking for better ways of doing things (regardless of current day best pratice)...that technique is (as I said above) old. I've used that exact approach for almost 10 years in MFC while building custom controls.
I'm not sure if there is a better way of solving this problem within the current context of PHP but there is no harm in asking as two heads are always better than one - so I asked. Nothing jumped out at me but I figured maybe someone else had spent significant time thinking about the problem and maybe discovered something worth mentioning.
ole...
I'll have to take a look into that other pattern you mention...
Thank you both for you time

Posted: Fri Dec 29, 2006 3:16 pm
by Ollie Saunders
I was basing my answer solely on your specific example. I think that says something: You can only make these decisions on a case by case basis. Attempting to form wide reaching generalisations will only lead to mistakes and frustration. Best course of action is to try and understand the thought processes a 'pro' goes through when making these types of decisions. For this you should check out books on oo that tell you about the principles the drive patterns and make them successful; I've mentioned Heads First Design Patterns but there are others. Refactoring by Martin fowler gets
great acclaim (comments are worth a look too) although I've never read it personally.
Re: inheritance/composition.
Composition, Composition and Composition! Inheritance just doesn't work in the long run. When I first started oo (in C++) I said to my lecturer "All the best classes are small, aren't they?" and he agreed. Unlike a lot of my misconceptions of best practice oo, that one has stayed true. So keep your classes, small, and numerous.
I was particularly badly burnt recently with the composite pattern. A known drawback to this pattern is just to cram more and more behaviour into the classes and, predictably, I did exactly that. One rewrite later I'd solved 50% of the problem but only realized there was another 50% to solve when I was near the end. I discovered a bug and realised it was actually impossible to solve it without changing superclasses really high up -- very bad oo indeed. I was suffering from what some might call "Primitive Obsession".
I'm on the next rewrite now and I'm confident I've got it right this time, I think I've learn that lesson now. But then again I thought that last time. So what I'm doing now is writing the whole thing up in UML and then developing by prototype; that is, leaving as many of the extras and details out and trying to implement the minimum you can that will still prove a oo design to be successful. If it isn't hopefully you haven't lost too much time and if it is you can easily continue to build on your prototype and you are likely to have something to show sooner. This is a bit like iterative development.