Thread: Intersect-test-solution, whats it called?

Hi, so i found a - in my eyes - nice way to allow code like this:

Code:

AbstractShape a = new Box(..);
AbstractShape b = new Sphere(...);

a.TestIntersection(b);

the idea is to get "multimethod" behaviour by using a visitor pattern like approach:

Code:

class AbstractShape
{
   public:

   bool TestIntersection(AbstractShape &r_other)
   {
        return r_other.TestIntersection_(*this);
   }


   // By default, an exception is thrown if the method is not overridden
   virtual bool TestIntersection_(Sphere &) { throw "not implemented"; }
   virtual bool TestIntersection_(Box &)  { throw "not implemented"; }
};


class Box : AbstractShape
{
    public:
    ...

    bool TestIntersection_(Sphere &) { // call the actual intersection test function }
}

This solution doesn't scale perfectly but i guess its ok. (For each shape a new method must be added to AbstractShape, and for each intersection-test implementation between 2 shapes each shape class must be updated.

The nice thing is, that this solution also allows deriving from a shape. So in my case i have a class OctTreeNode which is derived from Box, and i can still use the TestIntersection method on it.


Does anyone know if there is a name for that design pattern - or does anyone know where a similar pattern was used for intersection tests? I'm sure others figured out that solution, but so far i haven't found what i was looking for.

(Mostly i found ppl who used HashMaps or switch/if blocks, or used template "hacks" (typelists))

I just need something to cite for my work.
Thx

I don't know what it's called, but I think it started appearing around 1996.

With a good implementation of a generic dispatch engine, several exist, resolution of the specific function is still determined by a "best fit" principle. (You could further derive from child classes.)

The only real advantage of this particular form of implementation is the speed. (For most compilers the overhead is a small constant which can be "compiled out" in certain cases.) For most situations the maintenance overhead alone makes this implementation invalid.

I'm fairly certain that either "Effective C++" or "More Effective C++" discusses this implementation. If you have access to the book he may give credit to a particular older implementation and a name.

Soma

Thx for your reply

Well yes, as i said: It doesn't scale perfectly, but i guess for collision checking there aren't that many different shapes, so maintenance isn't impossible, and imo in this case the speed outweights this disadvantage by far (its just a virtual function call).

(Also, i only use this pattern to call the intersection test function that is kept elsewhere (so i dont have the actual code in the shape classes), so the shape-class implementations of these methods are just 1 line long, so its pretty readable).