2.1 Responsibility-driven versus data-driven approaches

It is often said that data are more stable than functions and so data-centred approaches are to be preferred in most cases. However, one of the greatest dangers in adopting a method based too much on structured techniques is that of data-driven design. Two software engineers at Boeing (Sharble and Cohen, 1994) conducted an experiment with internal trainees with similar backgrounds. One group was taught the data-driven Shlaer/Mellor method of object-oriented analysis - a method consciously and deeply rooted in traditional entity-relationship modelling - while the other group was instructed in the Responsibility Driven Design techniques of Wirfs-Brock et al. (1990). The two groups were then asked to design a simplified control application for a brewery. The Shlaer-Mellor group produced a design wherein most of the classes represented static data stores while one class accessed these and encapsulated the control rules for most of the application: in much the same style as a main{} routine in C would do. The other group distributed the behaviour much more evenly across their classes. It was seen that this latter approach produced far more reusable classes: classes that could be unplugged from the application and used whole. It also demonstrated vividly that the method you use can influence the outcome profoundly. It is our firm conviction that data-driven methods are dangerous in the hands of the average developer and especially in the hands of someone educated or experienced in the relational tradition. Furthermore, We hold that the approach taken to requirements engineering can have a huge influence.

The study by Sharble and Cohen shows convincingly that data-driven methods do influence the thinking of designers and that they tend to produce un-reusable classes as a consequence. The usual effects are that:

In our commercial practice we insist upon or encourage responsibility-driven design and analysis. We will be concerned throughout this text to emphasize this in all we do, just as we shall stress adherence to the basic principles of object technology: encapsulation and inheritance. This is not the pedantic reaction of a purist but a stance of immense practical significance.