What follows is a brief summary and discussion of a paper by Michael E. Caspersen and Michael Kölling entitled “A Novice’s Process of Object-Oriented Programming” .
In the paper’s abstract, the authors stress the problem of being “exposed to the process of programming in a way where ‘program’ is used as a noun rather than a verb.” The paper is a scaled down and abbreviated outline of an organized approach to programming not unlike that of the projects from my OOP class .
In the introduction, a problem is anecdotally expressed with a quote from Kent Beck. He describes his experience as a novice programmer, delving into programming books and learning to do things by rote until he felt comfortable enough to write his own program. As he sat in front of his computer trying to write a Star Trek game, he realized he had no idea where to start. “The process of program development is often merely implied rather than explicitly addressed”, say the authors. Despite his dogged efforts in front of instructional books, Beck had fallen victim to this.
When “rote processes give students understanding of isolated constructs but not a way to put them together”, significant stumbling blocks arise along the path to enjoyable programming. Reading his books, Beck saw the presentation of a problem and its solution side-by-side, without the steps in between. Those steps in between are discussed abstractly in this paper, in a way that a novice would be able to digest. “If [this] process is not explicitly taught, we end up with two types of students; those who cannot cope with the challenge of development and those who discover their own process.” The former might be compelled to quit programming permanently and the latter might fall into slipshod habits that will be difficult to break once a more pedantic approach is demanded.
Informed by stepwise refinement and top-down design, the authors provide the following list to the novice programmer attempting to write a class from scratch:
- create the class with method stubs; this is an easy way to subdue the overwhelming feeling of a new project, and will also help get some of the inevitable Javadoc out of the way
- create tests; there’s no reason not to start TDD as a novice
- create an “effort estimation matrix” for the methods of the class; this is a concept that is completely new to me, but is brilliant. I will try to use it at some point in the future. If the name isn’t self explanatory enough, here is an example: Implementation Effort R1 R2
method1() Hard Challenging
method2() Trivial Hard
method3() Easy Easy
4. define the instance fields as needed; this will demand at least partial implementation of the constructor
5. begin implementing methods; this can be summarized by the following two loops:
while there exists an unfinished method
pick an unfinished method
loop2() //implement the method
improve the method
Note that the order in which the methods are implemented is often arbitrary
6. Throughout the process, follow the “Mañana Principle”, which is defined as follows: if you wish you had a certain support method a while developing method A, write your code as if you had it and implement it later.
To illustrate the above process, the authors move on to a example date class, which becomes a component of an example calendar class. Since any reader who is still reading this post would skip reading that code, I have not included it. Concluding the paper, some related and future work is listed that a novice might study should he continue to program. This includes methodological approaches by Dijkstra, responsibility-driven design, XP/agile development, and stepwise refinement. Finally, the thesis is reiterated; software must be treated as a process of organized steps rather than a single monolithic solution to a problem.