Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re^2: Style or Clarity?

by periapt (Hermit)
on Jun 09, 2004 at 12:41 UTC ( #362704=note: print w/replies, xml ) Need Help??


in reply to Re: Style or Clarity?
in thread Style or Clarity?

Yeah, I do that a lot too. If you don't mind my asking. What exactly are dispatch tables and intelligent classes? I've seen dispatch tables mentioned before and I've always assumed that they were some table of subroutine calls, maybe in a hash? I've never had a clear idea of an intelligent classes. A little OT but it seems like a good time to ask.

PJ
We are drowning in information and starving for knowledge - Rutherford D. Rogers
What good is knowledge if you have to pull teeth to get it - anonymous

Replies are listed 'Best First'.
Re^3: Style or Clarity?
by dragonchild (Archbishop) on Jun 09, 2004 at 13:04 UTC
    A dispatch table is a data structure whose values are subroutine references. In C, this would generally be an array of funcp's. In Perl, it's generally a hash (though it can be an array).

    An intelligent class, in this context, is more of a group of classes. It's best explained with an example. Let's use the one from above - a bunch of menu items that may be displayed, depending on some set of external conditions.

    The immediately obvious solution would be to create some massive if-else structure to handle every obvious possibility. After about 3-4 distinct options, this becomes unmaintainable.

    The next solution most people arrive at is to create some massive data structure and some control function that will "walk the tree", so to speak. This is more manageable, but starts to become problematic around 10-20 distinct options. It also has issues if there is more than one set of external conditions.

    Intelligent classes is a variant of the latter solution. You still have the control function, but it's much simpler. It generally would look something like:

    my @list_of_classes = ( ... ); foreach my $class (@list_of_classes) { next unless $class->should_render( \%conditions1, \%conditions2, ... ); $class->render; }

    You then have a bunch of classes that all provide the should_render() and render() methods. They can be related through inheritance, or not. But, what they all do is determine for themselves whether or not they should render. This means that the conditions are broken out into the units that are smaller and self-contained, thus easier to maintain. When I use this method, I get up to 50 or 60 distinct options with 2-3 sets of external conditions and have no problem.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

    I shouldn't have to say this, but any code, unless otherwise stated, is untested

      Hey, that's kind of clever. So each class determines if the conditions are sufficient for successful action. I assume that the classes themselves are rigorously specific to one set of conditions since the partitioning of the condition space must be distinct.

      I don't do much OOP programming but I have been looking for a reason to try it. Maybe I've got a problem or two that might need this. Thanks

      PJ
      We are drowning in information and starving for knowledge - Rutherford D. Rogers
      What good is knowledge if you have to pull teeth to get it - anonymous

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://362704]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (9)
As of 2020-11-24 18:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?