Lists Home |
Date Index |
- From: "Thomas B. Passin" <firstname.lastname@example.org>
- To: email@example.com
- Date: Thu, 19 Oct 2000 21:53:24 -0400
Jon Cleaver responded to Roger Costello's post -
> Roger, All,
> There appears to be a convergence of thought that the
design of an XML
> schema is somewhat analogous to the creation of an Object
> for a piece of code. There are instances where you want to
> component reuse and instances where you want data to be
private. There are
> also instances where you want to combine both of these.
> What are the guidelines for creating private and public
members of an OO
> class? Is there a best practice for this - I assume there
must be one as
> part of an OO design course. Personally, I just decide
which components are
> needed to be viewed and which I would rather have left
> It seems to me that a fair chunk of this thinking will
have already been
> tackled by our OO design brethrin and there will be a
published set of
> guidelines. It is just a matter of finding them and their
> this problem.
Many principles for OO programming or design are the same
as for any other software development, and could (should, I
think) be applied to document or data design too. Among
1) Minimize interactions between components (or modules,
functions, objects, etc.).
2) Organize components into well-defined layers to help
minimize interactions. The goal is to have components of
one layer use only components from one other layer wherever
3) Anticipate what kind of extension might be desired in the
future, and provide for it now so that you can extend the
system with minimal disruption later.
4) Adopt a naming convention that helps explain the purpose
of each component, and use it.
These lessons (anyone should feel free to add more) have
been learned the hard way over the years. Why not take
advantage of them?