Skip to main content

Ambiguity

Posted by castelaz on August 31, 2004 at 9:13 PM PDT

I believe nearly every developer eventually creates their own metaphor for programming. Some are rather tame, such as “building bridges between users and systems”. Others can be quite aggressive. One of my coworkers will often say he’s spent his day “mangling bits” when things have not gone particularly well. As for me, I frequently picture myself with a large sledgehammer, squashing ambiguities. The gap between users and their systems isn’t so much bridged, as it is filled with the remains of ambiguities laid to rest.

Like a lot of programmers, I work hard to resolve misunderstandings between what is desired and what is delivered. In my opinion, it’s the hardest part of the job. At the same time, I’m thankful for the standard practices and idioms commonly found throughout the Java community. I wish I could say that the wonderful source level comments we write one another dispel all questions about intent, but the reality is that the idioms are sometimes our only guide to what the code was meant to do. This is especially true in terms of the public interface of a class or component. Even the best JavaDocs in the world will not solve the problems associated with a sloppy and contrary mix of common patterns and practices in a public interface. Ambiguities between developer and user are bad enough. It becomes extremely frustrating when they exist between programmers.

For instance, I recently came across a class that I couldn’t decide if it was a bean gone bad, or a singleton with an split-personality. I’ve changed the actual implementation to shield the guilty, but the sample below retains much of original class' flavor.

public class Foobar  {

public static String attribute1;
public String attribute2;
        public String attribute3;
private static Fooobar instance;

private Foobar() {
}

public static getInstance() {
if (instance == null) {
instance = new Foobar();
}
return instance;
}

public static String getAttribute1() {
return attribute1;
}

public static void setAttribute1(String attribute) {
attribute1 = attribute;
                notifyObservers();
}

public static viod setAttribute1NoNotify(String attribute) {
attribute1 = attribute1;
        }

        public String getAttribute2() {
               return this.attribute2;
        }

        public void setAttribute2(String attribute) {
                this.attribute2 = attribute2;
       }

       public String getAttribute3() {
                return this.attribute3;
       }
}

Now, I'm not about to critique the entire class, but even a quick glance shows there's something not quite right with it. The class begins by looking like a singleton with a private constructor and a getInstance method to control the single instance of the class. However, nearly all the other methods of the class are marked public static which makes the getInstance method unnecessary. Furthermore, the public static methods are mostly getters and setters for publicly available attributes which can be accessed from outside the getters and setters. Then, there is the problem of mixing bean-like behaviour with public getters and setters within the singleton. There may be a need for a singleton bean, but then you wouldn't mark the attributes public, nor would you make them instance rather than class variables. Even the experienced developers that I asked to review the code were hard-pressed to know what to make of the class. Is it a bean, a singleton, a bean-gleton? Finally, when you consider the class in the context of a large application, and the fact that the original is both much larger and more complex that the sample shown, you begin to realize that you have just meet the boss ambiguity for this level of the development game.

Standard practices, idioms, and programming conventions are important in that they help to minimize the number of ambiguities that exist between developers. Although we can argue endlessly what the conventions should be, our lives as programmers would be a lot tougher without them.

Related Topics >>