Monthly Archives: May 2012


As much as I enjoyed CS371p, my most valuable gains from it were not really from learning object-oriented best practices.  What the class helped me most with was the idea of creating coding standards and then enforcing them upon myself strictly.  This has more to do with what the professor wanted to impart than what the material necessitated, which makes me feel quite lucky to go to UT.  Writing UML and reading papers that discussed CS industry and culture further supplemented the “practical” feeling of the class.

I’m glad there was a points-based enforcement of pair programming.  I have found it easy to make acquaintances in CS, and pair-programming has turned several acquaintances into friends.  Granted, this is not the stated goal of having us pair program together, and certainly not the only reward, but even if I were to fail this class and dejectedly quit CS altogether, I would retain those friendships.

Without the information gained in OOP, I would likely have not have gotten a job this Summer.  Many questions asked throughout the twenty-something interviews I had were answered with information from the class, and several questions I missed were things that I would have learned in class had I been paying closer attention.

To summarize, great class.

Analysis of “A Novice’s Process of Object-Oriented Programming”

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:

  1. 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
  2. create tests; there’s no reason not to start TDD as a novice
  3. 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  
    while !finished
        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.