Software Design 2e - DIM

366Designing with objectsAn empirical study by El Emam et al. (2002) has examined the theory of ‘optimalsize’ for objects. This theory, arising from a number of sources, suggests that there is aU-shaped curve that relates the number (or density) of defects likely to occur in anobject to its size, and hence deduces that the ‘optimal’ size for an object will be at thebase of the ‘U’. On this basis, objects that are too large or too small are likely to bemore error prone and, for a given implementation form, there will be a size of objectthat is ‘just right’. However, their findings do not support this hypothesis, and showthat there is a simple continuous relation between the size of a class and the number offaults it is likely to contain.So what then does this imply for design? The first thing is that there is no magic‘right size’ for objects. This is an important finding in its own right, since if the existenceof such a ‘right size’ were to be the case, it would constitute an additional constraintfor a designer to have to incorporate into their design solutions. Secondly, thereis the degree to which larger objects are likely to contain more faults (and hence, designerrors). This is also a factor to be considered, and it does suggest that the use of verylarge and complex objects is likely to be undesirable.However, what we can conclude from this study is that what constitutes the ‘right’size for any given object should be a consequence of the needs of the problem, and notbe influenced by any implementation-related magic numbers.16.2.6 The case for reuseThe idea of reusing software is an attractive one, and has been so since the earliest daysof computing. Given that software is difficult to develop and debug, reusing tried andtested units of software provides one way in which developers can hope to improvedevelopment time while maintaining or even improving quality. Indeed, at a relativelylow level of abstraction, in the form of the library (usually of subprograms), reuse hasproved to be a very effective and widely used mechanism.Unfortunately it has proved difficult to progress from this level of reuse to achievereuse of larger units of software. Some of the reasons for this are technical ones. Usinglibraries is largely a constructional practice, and so reuse at this level has little effectupon the design process itself. In contrast, seeking to achieve reuse above that level canbecome a significant influence upon a designer’s decisions. Also, given that software isso pliable (or at least, appears to be), designers are likely to be less willing to accept theconstraints imposed by reuse than is the case in other domains, where fabrication is amore complex process. However, expecting that a unit should be modified as necessaryin turn removes much of the benefit of reusing tried and tested code. There is also atendency to design ‘made to measure’ solutions with software and, indeed, designmethods almost always assume that this is so, making little provision for explicitlyseeking to reuse existing previously developed part-designs. Equally, few methods (ordesigners) pay serious attention to the idea of ‘designing for reuse’ by explicitly seekingto design objects that will be reusable in other systems.(There are also organizational considerations that may encourage or inhibit reuse(Lynex and Layzell, 1998). While we do not have space to review these issues here, itis important to be aware that reuse is an organizational issue, not just a goal for theindividual designer or design team. Indeed, many of the serious barriers to reuse arelikely to be organizational rather than technical.)