Interviewees, in response to the initial question on “assess whether a program has been written using object-oriented techniques and practices,” talked more of the design characteristics that would be used in the construction of an object-oriented program. The novice practitioners (post-graduates) focused more on structural descriptions. The experienced practitioners were more abstract and less dependent on specific
terminology and concepts. This is reflected in the categories of description obtained from the interview data (see Table 5.3).
In discussing these design characteristics, the concept of an object-oriented program as a model of reality or a useful abstraction was evident. If design characteristics are seen as the ‘how’ of object-oriented programming, then the connection with an object- oriented program as a model forms the linkage to the more ‘what’ focused aspect of the nature of an object-oriented program.
In contrast to the previous categories where participants clearly stated their perspective, these categories had to be drawn from comprehending the emphasis in the interview. It was noted that participants fluctuated during the interview placing emphasis on different characteristics, or made limited use of terminology from a different category. There were also indications that participants may see some of the terminology as paradigm
specific, rather than as a more generic concept that has applicability to other programming paradigms.
A participant may have been reflecting a specific way of looking at object-oriented when they expressed a particular category within this outcome space. For example, a participant said:
“I mean Alan Fowler writes Fortran programs in any language, so I guess you would be looking for solving design problems by constructing objects at run time using dynamic dispatch or whatever you want to call it and
message sending using compositional objects to solve those kind of problems. That’s what I would see as the core of the OO designs” (I13).
The focus of this comment is on the coding level and the technical implementation. At this level, it makes sense to talk about “constructing objects” and “dynamic dispatch”. Later in the interview, the same participant said:
“I would emphasise just things like domain modelling. Try to be clear about what it is you are doing, what it is that you are modelling. I would
emphasise there are […] generally not any particular solutions to any kind of real world problem. There is really going to be more solutions than there are designers or programmers” (I13).
Here the participant has focussed on design issues; the language has changed to talk of “domain modelling”. As a result, the categories in this outcome space may reflect not simply a level of understanding but rather different perspectives or ways of viewing the same phenomenon within the object-oriented community.
To arrive at the design characteristics categories, the analysis looked at the overall emphasis placed on the use of terminology. It is the variation in emphasis and the changing terminology with respect to the design of an object-oriented program that distinguishes these categories. In many cases, the emphasis was clear because of the way the participant talked about the aspects.
These categories use a number of constructs, principles, qualities and thought processes that need further analysis to uncover the understanding that participants have of them.
The naming of the constructs, principles, qualities, and thought processes should not be assumed to have an obvious meaning. In the following discussion, some of the
difficulties in the use of terminology related to these concepts are referred to.
Cat Referential Structural
D1 Is language dependent This category represents a view that an object- oriented design is dependent on the use of the class construct in an object-oriented language.
D2 Uses paradigm constructs Uses specific object-oriented concepts and constructs D3 Uses generic principles Uses generic principles and concepts that have wider
applicability D4 Applies generic design
objectives
Uses design qualities that are general objectives for all programming
D5 Expression of thought process
Sees the object-oriented program as being the result of a specific thought process that addressed
particular design issues and programming problems
Table 5.3:Categories of design characteristics
D1) Is language dependent
This category reflects similar thinking to the second category of the outcome space ‘The nature of an object-oriented program’ (“Written using an object-oriented framework” (N2)). The emphasis, with respect to this category, is that the use of specific language features made the program object-oriented. At the lowest level, this was simply the use of class or inheritance constructs.
The use of this category as the foundation for this outcome space is to emphasise that some participants focussed primarily on structural components with limited discussion of design characteristics. This focus usually was at a low level of structure such as language dependency rather than the application of object-oriented concepts using the language.
This language focus is reflected in the following participant’s comment where the emphasis is on specific keywords rather than the object-oriented concepts implemented by those keywords.
“If it was a language I was familiar with, I would look for the keywords. The class construct if the language supported it. I don’t actually know if I’ve come across any languages that use objects that don’t specify classes. The keyword “this” is usually a good give away. It’s a lot of syntax I would look for rather than semantics” (I10).
D2) Uses paradigm constructs
The emphasis in this category is on the use of specific object-oriented constructs such as classification, objects, object identity, state, behaviour, interface, message passing, relationships, inheritance, and polymorphism. There may also be some emphasis on encapsulation as a way of constructing valid classifications for objects through the combination of state and behaviour together to hide the implementation details from potential users. In some cases, the participants discussed these constructs in terms of the technical implementation details.
For some participants, the use of paradigm constructs was reflected in the use of specific keywords or constructs such as “class” that the participant associates with object-oriented programming. However, this was not in terms of language constructs but rather in terms of object-oriented concepts. Here the participant was relating how they might determine whether some fictional program might be object-oriented. In this case, the participant had not been provided with the code examples
“Class definitions are going to be a bit of a give away that it’s object- oriented but if there’s no class definition in the code you’ve given me to look at, I’d be looking for the actual creation of objects to do work or I suppose, if something was being passed into a method and I could see that there were methods being called on that, I would assume that it was object- oriented” (I5).
For this participant, the keywords gave an initial indication but they also wanted to see that the code was actually making use of objects and not simply using the keywords. Although this next participant would be looking for keywords (“tags or labels”), the wording choice of “instantiate, collaborate, realise” suggests a particular style of usage rather than simply usage of those keywords.
“OO would have tags or labels that I would associate with OO. So words such as class, object, instantiate, collaborate, realise… what other words would I see?” (I12).
Some wanted to be more specific about the concepts that should be associated with object-oriented programming. In the following cases, it is inheritance and relationships.
“Programs written in it are designed with object-oriented programming in mind in the sense that they have classes, they have inheritance between their classes, there are relationships between data and everything, and there is some behaviour there but it’s always declared in terms of functions” (I1).
“These are the basic kind of building blocks of a good object-oriented program; for inheritance, delegation, interfaces, dynamic binding, encapsulation” (I11).
“I think the classic object-oriented things as being encapsulation, inheritance, polymorphism” (I19).
The use of object-oriented techniques should be more than simply being used to group things together. There should be explicit usage in the construction of the program that is coherent and meaningful in relation to the programming task being completed.
“If they’re unrelated chunks just grouped in packages then it’s not object- oriented. If there is a meaning like you can connect between that class and that class in many places and there is coherent structure rather than an unconnected structure then it’s more object-oriented” (I1).
The use of a particular object-oriented technique was seen as a requirement for object- oriented. If it was not used, then the program is likely not to be object-oriented.
“You can extend that and you can start saying “Is there a sensible use of inheritance amongst those classes?” for example. If they don’t use
inheritance at all, then I’m starting to think it’s been designed with a more procedural approach, more like C or something like that rather than making full use of object oriented ideas” (I6)
or
“In a class based language, I’d expect to see people inheriting things and using polymorphism” (I7).
Encapsulation was expressed as an object-oriented concept, but in the context that relates it to the creation of objects and the hiding of internal attributes. Encapsulation’s broader meaning was not recognised or considered.
“I’d look for the use of object-oriented concepts particularly things like encapsulation is probably the most important one from my point of view. ... People aren’t exposing member variables. The high level access is through accessors” (I19).
The emphasis on the paradigm concepts might be expressed in a way that connects with a higher-level understanding but with very limited focus on that higher-level of
understanding. In this case, the participant saw a connection with the real world and of an object-oriented program being a representation of the real-world but there was not a strong connection with the ideas of modelling.
“If we stick mainly to the general OO paradigm then there would be the whole idea of thinking about the world in terms of objects that carry some state and behaviour and same root. Probably this is the most basic aspect and then the various relationships between such objects and classes. Objects such as association and inheritance and then as far as inheritance is
concerned it would be polymorphism, in terms of being able to substitute one class for another thus having flexibility in the design” (I2).
This participant was more direct at other points in the interview making comments such as:
“In the real world, certain objects are related to other objects such as students are assigned or enrolled in papers so linking this paper object to student object in order to deal with this and we will have to reflect it
can be associated to paper, can be linked to papers and this is the association.” (I2).
Then, more bluntly in relation to the understanding of what an object is, this participant said an object is a “software presentation of real or conceptual objects in the real world” (I2). For this participant, the linkage between the use of object-oriented paradigm constructs and real world entities was the focus of object-oriented design.
Another participant acknowledged that, in creating an object-oriented program, the objective is to model the real world using the paradigm constructs. Notice that there is no specific reference to the quality of that model, although there is an implication here that this is a design process.
“Start modelling the real world, how will you go around doing that? Without asking a question why would you do that? We would describe classes and instance but then you need to introduce the actual things like inheritance and stuff and that’s where it gets tricky. I classify things but why do I need relationships between them. There is no real obvious relationship between many things in the world.” (I1)
and
“Object-oriented program will have a coherent model behind it. That model will have a reasonable classification of things into classes with relationships between them with just a little bit of inheritance of some sort or possibly interface inheritance. That model will have relevance to the problems being addressed” (I1).
In this participant’s language, there was a desire to see a close relationship between the use of objects in the program and entities in the real world. Another participant
expressed this same thought as:
“Everything’s an object and the objects within the system are a representation of those objects that are outside, that are the real world things.” (I12)
Another saw modelling the problem domain as the starting point for developing an object-oriented program and attributes this to being a Scandinavian approach to software development.
“You go out with the first cut of the domain model. The one thing I guess I believe in is using relatively straight forward modelling notations and techniques and processes because this is to help the people doing the analysis or programming to engage with the domain rather than having to worry much about the semantics of the modelling notation. I think object- orientation has a good a story coming out of Simula and Beta of the Scandinavian school. It’s a very nice story about the correspondence between object in the program and object or concepts in the real world.” (I13)
The shift that is evident in this category is away from an emphasis on language
constructs and keywords to an emphasis on constructs or concepts that are seen as being unique to object-oriented programming. Some interviewees attempted to list these concepts with some degree of closure. The use of the paradigm concepts was based on using them to model the real world.
D3) Uses generic constructs
The shift in emphasis in this category is toward constructs that are more generic and independent of programming paradigm. These constructs include abstraction, composition, delegation, encapsulation, modularisation, reuse, and type. In this category, the object-oriented concepts are seen as tools for implementing the generic concepts; for example, classes and inheritance are used to implement abstraction hierarchies.
Within this category, encapsulation is used as a more generic concept that relates to the enclosing of a piece of code, that implements some concept, within a programming construct to hide the details of its implementation. Encapsulation in this context was not limited to the definition of classes, but could be used in terms of methods, packages, or any construct that enabled the capturing of a piece of functionality and / or data in a way
that enabled reuse. This use of encapsulation is the same as that used by Shalloway and Trott (2005).
Like encapsulation, there were obvious differences in the use of terms such as
abstraction, modularisation, type, and design patterns. Design patterns were seen here as tools for constructing object-oriented programs rather than tools for assessing quality of design.
The use of the term ‘type’ presents its own set of problems. This was discussed in a number of interviews with the emphasis on type being defined by a class, through to a type being defined by a set of behaviours that might be defined by an interface or a class, or might be determined dynamically at runtime based on an object’s ability to handle a requested behaviour. The inheritance of type through class inheritance was also an issue in this discussion. This is an area where further analysis is required.
Modularisation was used in a number of different ways but two stood out in particular. One usage was in relation to functional decomposition and imperative programming, and the other in a more generic sense of combining code elements into larger chunks. In the case of object-oriented programming, these larger chunks are classes, packages, applications, or programs.
Abstraction is another area where there was considerable difference in the use of the term in the interviews. Abstraction was used with reference to different levels of the code such as classes, methods, packages; and also used in reference to different levels or categories of proximity to a perceived reality. This also needs further investigation and analysis.
Generic concepts were often discussed in connection with good design and in relation to other generic constructs. They were also linked with paradigm specific constructs primarily in the context of the generic concept being implemented through the use of a paradigm specific concept.
For this participant, the focus was on modularisation through decomposition to objects with the objective of improving reuse.
“When you break down a system in terms of objects, you’re getting parts that are potentially reusable elsewhere so we look at trying to minimise dependencies and we definitely do look at decomposition in the context of objects” (I11).
Encapsulation of data to form new “abstract data types” was also closely linked with modularisation. This was seen as a method of abstraction and as a way of “enforcing design as intent”. Although referencing design in this context, this participant was not talking about design objectives, however these may be perceived as being present in the background.
“When talking about abstract data types that’s an opportunity to introduce some examples to show that if you don’t encapsulate the data, it’s open to abuse by programmers and so on. So it’s not just that you’re getting abstraction with abstract data types, you’re also getting protection. You’re enforcing policies in the software. You’re enforcing design as intent” (I11).
This emphasis on generic constructs with an emphasis on reuse through design patterns was seen as a way of defining software development as an engineering discipline.
“It’s often difficult to defend software development as being an engineering discipline but the use of design patterns is basically reusing tried and tested design knowledge and that contributes to higher quality and reduced costs of software development and that’s basically what engineering is all about” (I11).
Another participant, while focusing on generic principles, focused on modularisation