Patterns and Idioms in the DejaVu Framework

Anton Eliëns, Jacco van Ossenbruggen & Bastiaan Schönhage
Vrije Universiteit, Department of Mathematics and Computer Science,
De Boelelaan 1081, 1081 HV Amsterdam, The Netherlands
email: {eliens,jrvosse,bastiaan}@cs.vu.nl, fax: +31.20.4447653

Abstract

abstract

The DejaVu framework, in particular the hush (hyper utility shell) library and its extensions, aims at providing an easy-to-use and flexible, multi-paradigm environment for developing distributed hypermedia and web-based applications. Our framework is object-oriented in that it allows for a component-wise approach to developing applications. Yet, in addition to object class interfaces, it offers the opportunity to employ a script language to develop applications and prototypes as well. It is multi-paradigm, not only by supporting a multi-lingual approach, but also by providing support for distributed client/server solutions in a transparent manner.

In this paper we will discuss our experiences in developing the framework with regard to the method of software development employed, recurrent patterns in the design of components, and, on an architectural level, the problems in supporting multiple languages and distribution.

We will discuss the scope of our framework and the approach taken in its realization as a collection of classes. In particular we will delineate the recurrent patterns that we employed in its design and, on an architectural level, the idioms we employed for the concrete realization of the basic concepts underlying the framework. To illustrate the role of the patterns and their associated idioms in our framework, we will discuss the construction of our Web components.

We observe that there is a tension between defining a clean object model and providing the flexibility needed to support a multiparadigm approach. We resolved this tension by choosing to differentiate between the object model (that is class interfaces) offered to the average user of the framework and the object model offered to advanced users and system-level developers.

In our work, idioms play a central role, that is we achieved the desired flexibility by systematically employing a limited number of basic idioms. We succeeded in hiding these idioms from the average user of the framework. However, the simplicity of our original object model is only apparent. Advanced or system-level developers who intend to define extensions to the framework must be well aware of the patterns underlying the basic concepts, that is the functionality requirements of the classes involved, and the idioms employed in realizing these requirements.

Patterns and their associated idioms have guided us in defining an architecture that allows for transparently extending the functionality of our framework. However, with respect to issues of distribution, the idioms employed provide only a partial solution. To realize a framework for distributed applications, we have felt the need to provide additional language support as well, that is by extending existing O-O languages with support for parallelism and distribution.

Our framework has evolved gradually over the years. Reflecting on the approach we have taken and the problems encountered, we will evaluate the relative merits of employing patterns and indicate the costs, in terms of development efforts, incurred by using them in the realization of our framework.

Keywords and phrases: object-oriented framework, multiparadigm, distributed hypermedia, web-based applications, patterns, idioms, languages, development costs


Postscript
eliens@cs.vu.nl
Wed Oct 23 21:43:55 CEST 2013

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