With respect to meeting the requirements of flexibility and extensibility, our approach has proved its worth. However with respect to the software development efforts involved, the systematic application of the idioms described has drawbacks as well. For example, we found that applying (the naive version of) the handle/body idiom led to disrupting the virtual function call mechanism and hence to inconsistencies in the class hierarchy and additional coding effort. Our improved version solved the first two of these problems. Also, we found that the use of separate body implementation classes gave rise to the introduction of many additional classes. To avoid a pollution of the class name space, we decided to export only a limited number of classes and to employ a suitable idiom for hiding the concrete subclasses.
To evaluate, our experiences are positive, but we had to pay a price.
First of all, applying the idioms led to a
significantly increased design effort,
and secondly, additional coding effort (and discipline)
is needed for implementing system level components.
In the table below we
give a qualitative assessment of how the use of idioms
may affect, in our experience, aspects such
as reliability,
adaptability, maintainability
and performance
| Requirement | body/handle | virtual self | role-switching |
| Reliability | +/- | - | - |
| Adaptability | + | +/- | ++ |
| Maintainability | + | + | - |
| Performance | - | - | -- |
No doubt, adaptability is improved by employing the handle/body idiom and even more by employing the role-switching idiom.
The aspect of maintainability is positively affected by applying the handle/body and virtual self idiom, yet moderately negative by role-switching.
In terms of both memory usage and run-time efficiency, loss of performance will result from applying idioms. Apart from the creation and deletion of additional objects, additional object references are required as well as additional de-referencing and, in the case of role-switching, array indexing or hash table search. Nevertheless, the performance loss is certainly not dramatic, in particular with regard to the benefits of having a single uniform interface for the application programmer and at the same time the flexibility needed in a research environment.
Concluding, we have stated our experiences which indicate that patterns are profitable but also that "patterns do not come for free". On the contrary, the employment of patterns and their associated idioms incur significant costs in terms of software development efforts and, in addition, may affect the quality of the software with respect to aspects such as reliability, maintainability and performance.