Lessons learned


introduction framework patterns components conclusions references appendix experience
Addendum to Patterns and idioms in the DejaVu Framework
  1. In developing a framework, an object-oriented approach facilitates ease-of-use and maintenance for user applications employing the framework. However, development costs for the realization of the framework are inversely proportional to this. Maintenance of framework code is difficult, and reuse of code is minimal. Patterns must be introduced to compensate for a lack of support (e.g. part-whole hierarchies) in object-oriented languages.
  2. Merging an object-oriented approach with patterns to allow for flexibility and interface inheritance significantly complicates development at a system level. Additionally, naive implementations of patterns interfere with traditional OO concepts such as inheritance and the virtual function mechanism.
  3. A distributed architecture has proven to increase the complexity of the framework with an order of magnitude. Tackling issues of distribution is only weakly facilitated by an object-oriented approach. Similarly, apart from allowing for the reuse of ``abstract'' interfaces, patterns do not contribute significantly in this respect. Rather, to develop a framework for distributed applications additional language support is needed.
  4. Patterns contribute significantly to the extensibility and flexibility of the framework. They allow for providing a simple, uniform class interface, while hiding to a large extent low-level platform dependent implementation details. However, such details creep up when application programmers require more functionality.
  5. For the realization of the framework, the right choice of idioms and a systematic application of them is of crucial importance. Patterns are needed to explain the rationale of using idioms and to clarify the rules of thumb guiding their use.
  6. Our understanding of the use of idioms and the patterns realized by them has evolved gradually. Each step in becoming aware of their role necessitated a full iteration of the development effort, that is rewriting the code and adapting the design. As a result, interfaces became more stable. Yet additional features were added to be able to hide the implementation details and prevent ever growing class interfaces.
  7. In the area of distributed hypermedia, our work shows that a suitable script interface is essential in supporting a flexible environment, that allows for a smooth transition from rapid prototyping to an application with a stable object model.
  8. The use of patterns and their associated idioms may lead to an explosion of the class name space unless precautions are taken, that is special idioms are introduced, to avoid such an explosion. As a result, however, the concrete object model may differ from its idealized version that is presented to the user as a collection of ``abstract'' interface classes. In some cases solutions have to be completely rewritten to fit them in the framework. As a consequence, maintaining and extending the framework requires a high degree of design and coding discipline.
  9. Managing a framework development project requires continuous attention for the definition of the basic concepts and classes constituting the framework. In addition, strict guidelines for creating extensions must be formulated. System programmers must be trained to use these guidelines effectively in the design and implementation, but such training has a positive transfer to other development activities.
  10. All in all, we are positive about merging object technology, patterns and client-server solutions. In a research environment, the development of our framework proved to be an inspiring exercise which contributed significantly to our understanding of object-oriented software development. When time-to-market aspects would have been involved, the problems mentioned might have been a bigger nuisance. Moreover, finding the right idioms and discovering the patterns involved may require more time than a company interested in shipping a product is able to invest.

introduction framework patterns components conclusions references appendix experience