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