Re: How much oop is too much oop?
- From: Jerry Coffin <jcoffin@xxxxxxxxx>
- Date: Tue, 26 Apr 2005 22:54:56 -0600
In article <u#Kv5PjSFHA.204@xxxxxxxxxxxxxxxxxxxx>,
dave@xxxxxxxxxxxxxxxxxxx says...
[ ... ]
> I suspect the trouble may be that the text books tend to give
> examples based on a single object hierarchy. When you have dozens
> of different objects collaborating in a task, then forbidding one
> from asking another about itself and what it can do is extremely
> counter-productive.
Rather the contrary -- it's often a good thing to do. Allowing such
questions to be asked almost always leads directly to _requiring_
that they be asked to use them correctly. This means two things: that
each class has to acquire knowledge about the other classes to use
them correctly (breaking encapsulation) and that the compiler can't
do much to enforce the restrictions about what objects can be used in
what ways.
> To continue my trivial example you may have a "plane surface object"
> which wants to tile itself with a given shape. It is extremely
> convenient if it can ask the shape whether it is one which can be
> used for this purpose (like a square or regular hexagon, but not a
> regular pentagon). Why hamper things by forbidding the question?
This displays both of the shortcomings outlined above. To work
correctly, the plane class has to know allows a shape to be tiled (or
prevents it from being tiled), and the compiler can't do anything to
enforce the correct use of shapes, preventing attempts at tiling with
shapes that can't be tiled.
If tiling is important in your application, you can make that
explicit:
class shape {};
class tileable_shape : public shape {};
struct plane {
tile(tileable_shape const &s);
};
and now the compiler knows that only tileable_shapes can be used to
do tiling, so it'll enforce this restriction. Likewise, the plane
class doesn't need to "know" anything about what makes a shape
tileable or not -- it just knows that tileable_shapes are tileable,
and others aren't.
One of the basic ideas of the type system is to explicitly encode HOW
types can be used, so when/if you find yourself "asking" an object
whether it can be used in a particular way/for a particular purpose,
what you're doing is creating your own type system -- but you're
fighting the compiler instead of using it.
Of course, it's also possible to go overboard with this -- attempting
to encode _lots_ of characteristics into the types can lead to deep,
brittle hierarchies. In some cases, this may simply reflect a messy
problem domain (e.g. natural language analysis). More often, however,
it reflects a lack of understanding of the problem, so the much
smaller group of general rules that _could_ be applied haven't been
recognized and applied.
--
Later,
Jerry.
The universe is a figment of its own imagination.
.
- Follow-Ups:
- Re: How much oop is too much oop?
- From: David Webber
- Re: How much oop is too much oop?
- References:
- How much oop is too much oop?
- From: ben
- Re: How much oop is too much oop?
- From: Gene Bushuyev
- Re: How much oop is too much oop?
- From: David Webber
- Re: How much oop is too much oop?
- From: Nemanja Trifunovic
- Re: How much oop is too much oop?
- From: David Webber
- How much oop is too much oop?
- Prev by Date: Re: How much oop is too much oop?
- Next by Date: Re: File open problem
- Previous by thread: Re: How much oop is too much oop?
- Next by thread: Re: How much oop is too much oop?
- Index(es):
Relevant Pages
|
Loading
