Having now spent six months working back in industry having completed my thesis on practitioner perceptions of an object-oriented program, I have been seeing the practical out working of some of the findings in my thesis. My thesis focused on the way that practitioners expressed their understanding of an object-oriented program. In analysing the interviews that I conducted, I looked for aspects in their descriptions that clearly distinguished the way that the practitioners perceived an OO program.
The results of my produced two hierarchies of perceptions. The first related to the nature of an object-oriented program and the second to the design characteristics. The critical aspects for the nature of an object-oriented program are flow of control, object usage, and problem solution. For the design characteristics, the critical aspects are technology, principles, cognitive process, and modelling. If you want to gain more insight then I suggest that you read my thesis.
In doing the data gathering for my thesis, I never collected code examples so I can only draw conclusions about the type of code produced by the practitioners based on what they said in their interviews. However, in the workplace, I am seeing those different perceptions in action and seeing differences in the type of code produced.
One of the key differences relates to the use of classes and the size of classes. Where the emphasis in flow of control tends towards a procedural or imperative understanding, I am seeing objections to using classes for the separation of concerns and a willingness to create classes that have large numbers of often long methods.
There is one area where this is very noticeable. The original architecture used an MVC pattern with commands to perform asynchronous requests for data. In the framework being used each asynchronous request has a command, an event, and a method in a delegate class. Linking these all together can prove quite tedious as can creating the individual commands and events. The commands and events have a very similar code structure.
One solution to reduce duplication in the code base is to factor out the common code into super-classes within a class hierarchy. To further reduce the duplication, consistent parameters can be established for the asynchronous requests further eliminating the differences in the command classes and possibly eliminating the need for some altogether. Further refactoring could be used to ease the programmer knowledge on the underlying event structure. In one stream of the project, this is the approach that has been taken, although not as yet to its full extent.
In another stream, the individual command classes have been eliminated by pulling them all into one big class with a method for each of the asynchronous requests. Each of these methods have similar structure and in many cases similar operations. Additional framework code has been produced to manage the new class structure. The number of classes has been dramatically reduced but the size of the classes has increased. This approach has the advantage that the programmer simply calls the appropriate method for each request.
As I look at the differences, I see a clear difference in the perceptions that the programmers bring to the task. If the code base differences are to be addressed then theses differences in perceptions need to be dealt with and resolved.
What this situation raises for me is another future direction for my research. There is a need to analyse code basis produced by different programmers and to interview them about why they wrote the code the way that they did. The interviews would be designed to uncover the perceptions that the programmers have of the task that they are working on and what they perceive as the essential design characteristics. This type of research would extend my work further into the practitioner space rather than the current educational focus of my thesis.
The question is whether funding could be raised for such research.