Unlike the nature of an object-oriented program outcome space where the aspects became visible during the process of uncovering the categories, the critical aspects for
the design characteristics outcome space were identified as a second stage in the analysis. The critical aspects were identified by carefully examining the characteristics of each category and its distinguishing features. Each of the identified critical aspects focuses on a particular theme that is evident in the design characteristics outcome space (see Table 5.4).
Critical Aspects Cat Referential
Technology Principles Cognitive process Modelling D1 Is language dependent Constrained by language features Language features determine principles applied Need to know the language D2 Uses paradigm constructs Constrained by paradigm constructs Paradigm constructs determine principles applied Thinking in terms of objects Reflects real world objects D3 Uses generic principles Implementation tool but paradigm specific Paradigm independent principles drive design decisions Thinking in terms of good coding practices Reflects real world objects D4 Applies generic design objectives Implementation tool but some flexibility on paradigm Design objectives drive design decisions Thinking in terms of the impact of design decisions Uses useful abstractions D5 Expression of thought process Implementation tool but select paradigm to match Thought patterns implement design principles Implicit recognition and correction of poor design Communicate program design
Table 5.4:Design characteristics critical aspects
The technology aspect is the degree by which the implementation is constrained by the technology. In category “D1: Is language dependant”, the focus is on the language as the constraint to design. The features of the language dictate what is possible and how the program is structured. For category “D2: Uses paradigm constructs”, there is a shift away from the specific language features to paradigm constructs. At the higher levels, both the language features and the paradigm constructs become primarily
paradigm constructs are seen more as patterns of thought than as technological solutions. For the higher three categories, the technology is the slave of design or the thought processes and not the focus of design. With the shift to the thought process, there is a willingness to mix and match paradigm and technology tools in order to satisfy the design and thought process requirements.
The design principles aspect sees a shift from focusing on the technology restricting the design to a focus on generic principles of design. Design for the “D1: Is language dependant” category is about using language features to modularise or structure the code. The design focus shifts to what the paradigm constructs allow for category “D2: Uses paradigm constructs”. With these first two categories, the technologies drive the design decisions. Although this may allow some code reuse and design for ease of maintenance, these more generic principles or design objectives are seen more as a result of using the technology than as objectives that determine the approach taken in using the technology. The generic principles begin to drive design choices for category “D3: Uses generic principles”. This may see the use of implementation patterns and principles of code reuse dominating the design. Here the implementation patterns may be constrained by the paradigm or the language, but the focus is moving away from paradigm specific concepts and toward principles that apply across paradigms. The implementation patterns are ways of implementing the generic principles for the given paradigm and programming language. For category “D4: Applies generic design objectives”, the focus is on the design objectives. The approach to design is driven by these objectives rather than by any language or paradigm constraints. There is a possibility at this level that the programmer will mix and match languages and
paradigms to fit the required design objectives. For the final category “D5: Expression of thought process”, the shift is toward patterns of thought that led to good design. The design principles do not dominate the thinking but they are consistently applied through having become tacit principles for the design of good code.
The third aspect is called cognitive process as the focus is on the thought processes behind the approach to creating an object-oriented program. The distinction between the categories is related to ‘what’ the thought process is focused on, rather than a distinction in terms of the cognitive skills being utilised. At the lowest category, “D1: Is language dependant”, the focus is on knowing the language in order to be able to write programs.
Knowledge of the language is more than simply being able to identify, recall, and apply language constructs; the programmer needs to be aware of the appropriate use of
constructs. The cognitive process moves to thinking in terms of object-oriented principles for the second category, “D2: Uses paradigm constructs”. Here the focus is on the use of objects as required by the paradigm. Like the first category, this involves identification, recall, and application of paradigm constructs. With “D3: Uses generic principles”, the focus moves to good coding practices. The technologies are simply tools for the production of good code that satisfy the principles. At this point, the programmer begins to break away from paradigm dependency and have a flexible approach to the use of a range of paradigms. The transition to “D4: Applies generic design objectives” takes the focus to an emphasis on the impact of design decisions. The influence of the paradigm is more from the perspective of how it helps generate a good design. The programmer may mix and match programming paradigms if that delivers a better design. The final category, “D5: Expression of thought process” sees a shift to the point where there is an implicit recognition and correction of poor design. In the preceding two categories, the programmer may be guided by design patterns but with this top category, the programmer works to eliminate code problems through recognition of what are called ‘code smells’ (Fowler, 1999) and applies strategies to eliminate them. The paradigm is irrelevant other than in how it can be used to support the thought processes.
The fourth aspect is a focus on modelling or the production of a model. The lowest category, “D1: Is language dependant” makes no reference to the program as a model or programming as modelling. At the next two categories, “D2: Uses paradigm constructs” and “D3: Uses generic principles”, modelling is emphasised in terms of the program being a model that reflects real world objects. The programmer’s task is that of modelling the real world using object-technology and / or the application of generic programming principles. For the fourth category, “D4: Applies generic design
objectives”, while there is still a real world focus in providing a starting point for design or hints of possible objects to include in the design, there is a recognition that not all real world objects will be modelled and that other objects, which are seen as useful abstractions, will be included. The created model has to be seen as delivering a useful solution that satisfies the required design characteristics. For the final category, “D5:
Expression of thought process”, the emphasis is still on useful abstraction but with an emphasis on how those abstractions communicate the program design.
5.2
Conclusion
Two outcome spaces, which relate to ways that practitioners express their awareness of an object-oriented program and the design characteristics used in implementation, have been described in this chapter. These have been further analysed to identify the critical aspects that distinguish variations in awareness expressed by the practitioners.
The first outcome space focuses on structural descriptions and is more technical in focus. This is a focus on the ‘what’ aspect of programming in the sense of what is produced. It describes the characteristics of the program from the perspective of how the program is executed (flow of control critical aspect), the way that the paradigm building blocks (objects) are used (use of objects critical aspect), and the focus on the program as a model derived from either data or behaviour (problem solution critical aspect). In this outcome space, there is a shift from following a set of instructions through interacting entities to the idea that the concept of a program is an artificial construct created for the requirements of operating systems. This latter description frees the developer from the restrictions of program boundary to explore the use of reusable functionality as the units developed in programming. Each of these categories builds on the lower categories, but there is a clear shift in emphasis in the way software is understood from a structural perspective.
The second outcome space focuses on design characteristics and begins to consider the issues of what makes a good object-oriented program or how a program is written. At the lower levels, design quality is less of an issue and the focus is on the technologies (i.e. the language constructs or paradigm specific constructs). The shift to generic constructs suggests that some constructs are applicable regardless of the programming paradigm. The shift to design qualities further moves toward generic characteristics or properties of a program. Finally, the expression of a thought process offers a challenge to further explore the way that expert programmers think, and to explore how novice programmers can learn these thinking processes. These thought processes do not neglect an understanding of design qualities or the paradigm or generic constructs, rather these thought processes leverage the paradigm or generic constructs to produce good designs
that are not constrained by paradigm specific constraints. These thought processes suggest that there may be ‘programming in the small’ patterns that, if used consistently, deliver quality program designs.
There is a difference in the way that the practitioners focus on the critical aspects in the two outcome spaces. For the nature of a program, there are different variations in the expressions of awareness of the critical aspects which provided the differentiation between the categories. With the design characteristics outcome space, there is more of a change in focus with respect to the critical aspects. At the lower categories of the outcome space the focus is on the technology critical aspect. It then moves to the design principles critical aspect through the middle categories and with the highest category, the cognitive process critical aspect is the primary focus. The higher level categories do not ignore the technology critical aspect but see it as taking a subordinate role. The modelling critical aspect reflects how this shift in focus on the other critical aspects influences the approach to producing a program and the nature of the resulting program.
In the following chapter, the critical aspects underlying the outcome spaces will be used as a guide to the analysis of a number of textbooks that introduce object-oriented
programming. The objective is to determine whether textbooks utilise similar aspects to those discussed in this chapter and what is the space of learning in these texts.