Reusable systems

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Reusable systems

Post 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 :)
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post 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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post 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... :P

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 :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post 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
User avatar
Buddha443556
Forum Regular
Posts: 873
Joined: Fri Mar 19, 2004 1:51 pm

Post 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.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post 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 :)
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post 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.
Post Reply