"Fredrik Jagenheim" <fredde / pobox.com> schrieb im Newsbeitrag
news:20030909085851.GB28065 / pobox.com...
> Hi,
>
> First a little warning, this post is more of a rubberducking session
> than a proper question.
>
> I have a rather trivial problem, but since I'm spending 8 hours a day
> cursing C++ and far coding in Ruby, I'm afraid I can't think of a
> proper Ruby solution, and instead come up with 'this is how it
> could've been done in C++'-solutions.
>
> The problem: I have a data set. I'd like to see if this data set
> fullfills certain properties, so I did a couple of classes which will
> do the matching against these properties:

My first question would be, do you want to be able to do the checks
individually or do you want to always apply all checks?

[snip]

> Anyway, then I started to think about using a superclass for these
> classes and use Ruby introspection to find all the subclasses and call
> match from there.

That's what I'd do.  It gives you the flexibility to execute each
individual test if you need it and provides for easy finding of all tests.

> That's when I realized there must be simpler
> solution I just can't see...
>
> Perhaps extending the set-class with the methods;
>
> def MatchB
>     def match_b?
>         # Complex calculation
>     end
> end
>
> set.extend(MatchB)
>
> puts "Matched B" if set.match_b?

No, this seems overly complex to me and (more important) these tests have
nothing to do with Sets per se.  You should then create a sub class of Set
that contains all match methods.  But the other approach (individual
classes per test) is more modular, flexible and easier to extend.  If you
hava a single Set sub class that contains all tests you'd have to use
something like this for all matches

def all_matches?
  public_methods.grep( /^match/ ).each do |m|
    return false unless self.send m
  end
  true
end

> It probably be the best way OO-wise, since it's a property of the Set.

I regard the single test classes better OO wise, since they all implement
a single interface you you don't have to do method name tricks to find all
tests.

> Or am I really wrong here?

No, I think you picked the reasonable solutions.

Cheers

    robert