[AccessD] Framework Discussion - Who's following this

Ken Ismert KIsmert at TexasSystems.com
Tue Mar 9 14:38:23 CST 2004


1. a
2. a
3. a

Three suggested guidelines for frameworks:

 * Simplicity drives adoption. No matter how complex the framework becomes,
if it is made of small, easy-to-validate parts, it will tend to be reliable
and maintainable. Well-factored code, careful choice of object boundaries,
and attention to naming makes the framework easier to understand and use.
 * Define boundaries. No matter how well thought-out and abstracted a
framework is, perfect generalization is elusive. Deciding what the framework
will and won't do beforehand guides development, and helps keep feature
bloat from delaying a timely finish.
 * Accept the limitations of your platform. Frameworks can't make up for
system shortcomings. If VB doesn't shutdown an application opened through
automation when you set its reference to nothing, there is nothing within
the system that you can do to fundamentally fix it. You can write standard
handlers for such situations, but you can't force the user of the framework
to use them. In cases like this, education is the best approach.

Write code that is spare, obvious and well thought out, like Shaker or
Biedermeier furniture.

-Ken




More information about the AccessD mailing list