> I'd only use interfaces for preventing too much coupling between
> methods/classes: using an interface as a restricted view on an object.
> What do you mean by introspection? Querying an object for having an
> interface and then using the appropriate methods? I'm not sure if I
> like
> this.
Not at all, I wouldn't like that either. What is meant by
introspection is having an interface whose *sole* purpose is to just
provide a descriptor of that object (a property, per se), then it's
usually better off being data driven as it simplifies the interface
and types. An example ...
> Can you give an example of the 'data-driven' approach?
Consider in the previous example where we have some object and we
want to designate that it can be rotated. There's plenty of "right"
ways to do this with various tradeoffs. In our example, we had
Rotatable as an interface to that class. That's all good and well,
but if the only benefit of having that interface amounts to just
being a boolean flag, then it could very well just be made a boolean
value or method on that base geometry object class instead. That
becomes data-driven.
So instead of interfaces:
class Geometry : public Rotatable, public Scalable, ... { }
you push the information into the class as data:
class Geometry { bool isRotatable, isScalable, ...}
Whether that's a good or bad example really depends on what else
those interfaces were doing, of course, but hopefully explains it.
Another (albeit extreme) example could be how you identify geometry
database objects. At the I/O layer, instead of encoding N classes or
N interfaces for N object identifiers, with data-driven you'd just
embed the ID in the class (where it can have N possible values).
Depending on the situation, it can often be far more simple and less
brittle to maintain. (Again, just a general example, not saying
that's how that particular portion of the API should be done.)
The tradeoff is usually if all you're going to end up with is a table
of types (whether via rtti or not), then it's often/usually much
simpler to just make it data-driven favoring a slightly bigger class
implementation in order to reduce complexity and C++ type hacks.
Cheers!
Sean
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
