[MUD-Dev] Languages

[Jon A. Lambert]

> From: Shawn Halpenny <malachai at iname.com>
> Caliban Tiresias Darklock wrote:
> > The problem I see in projects built using proper OOP in C++ is that the
> > same data is validated over... and over... and over... and over...
> > because none of the objects can make any assumptions about the others,
> > so they can't ever take for granted that someone else has validated the
> > data. If they did, they'd break the whole reuse thing.
> 
> That reflects poor design in the reuseable components, IMO--or at least
> in the documentation of them.  I'm a proponent of the "validate as close
> to the input source as possible" school of design, and if the interfaces
> are properly documented in those objects close to the source, there
> should be no reason for data to be validated ad infinitum.
> 
I would strongly disagree with this.  That reflects excellent design
of reusable components.  A reusable component such as socket classes,
data structure classes, file access classes and others should be as robust 
as possible and make no assumptions about input.  You should understand 
that this is what makes a class library truly reusable.

If you are writing custom classes designed ONLY to be used within your
mud app then you are right.  This validation would appear to be
redundant.  If you make a decision to compromise class integrity to 
gain performance at this point, you are also making decision that will
decrease the class reusability.  I prefer to defer any decisions 
along this line until my application is complete.  If code profiling
shows performance problems, only then would I optimize.


JL