At 02:13 PM 1/30/01 -0500, Bakki Kudva wrote:
>I am studying mod_perl and the GoF Desing Patterns book in parallel and
>had a few questions I would like to throw to the list.
>
>1. Is there anyone who is using GoF design patterns (eg. Chain of
>Responsibility for handlers) in their mod_perl apps?
Yes. The most common is filtering content. There are a lot of mod_perl
specific filters.
If you look at the latter half of the on-line book at
http://www.extropia.com/ExtropiaObjects/ and read the module chapters after
and including the "Architecture" chapter you will see a sidebar in each
chapter devoted to identifying design patterns that were used in that set
of related modules.
eg we use CoR in filters that are specific to handling content in our apps.
We use (depending on how you view it) CoR or flyweight for dealing with
stuff like data handlers (which are essentially filters for *incoming*
content)
>2. Is the overhead of OO Perl acceptable for mod_perl apps, generally
>speaking?
Yes. Very few people really need to eek out all the speed in world. Most
people just want fast apps, they don't need the fastest apps. That's one
reason why PHP and Microsoft ASP is so popular... they're fast or rather
fast enough without being hard.
Mod_perl could be a lot faster than PHP but it's more of a learning curve
for people who don't know Perl well.
>3. Are there any new patterns useful for mod_perl apps?
Lots. But I think you mean Web apps not mod_perl apps. Web Apps abound with
idioms and design patterns. There are many which have been identified since
the GoF book such as Session which I think nearly all large web apps use. :)
>4. Am I wasting my time with OO and design patterns if the goal was
>writing a mod_perl app?
I guess it depends on what you mean by a mod_perl app. If you mean a web
app that runs on top of mod_perl, then you should use good OO because I
suspect you'll want to expand that app and do things later with it which
means the cost of maintenance is an issue not just the speed.
If, however, you are writing some custom auth handler or something like
that, then the efficacy of sticking to OO is less because (A) Yes, you
could lose some performance in some cases, and (B) Because the auth handler
is likely to be so tiny that OO would not make sense. OO is better for
larger programs so that they can be broken down more easily.
My personal experience is that web programs tend to fit the bill for OO if
they go beyond simple 1-off logic such as form processing. I think OO is
overkill if all you would have is just one object because the program is so
simple.
Later,
Gunther
PS Caveat: Don't go overboard on design patterns. GoF book was written with
typical apps in mind. Web apps were not in their view scope at the time.
Web apps do operate differently to regular apps and the design patterns or
idioms you might wish to use may be different. Since as the GoF book puts
it, all patterns have their advantages and also their consequences. Those
consequences may be OK for a regular app but not for a web app.
There have been tons of articles and books on Design Patterns since GoF
book was out. It's good to absorb GoF, but don't use it to hammer
everything because you've read something new and cool. Asking your
questions certainly shows you seem to understand that anyway, so I am
probably preaching to the choir. :)
