CertPal

While coming up with APIs or a framework, design forms a crucial part of the end result. While a solid design does indeed allow for flexible usage of an API, usability goes hand in hand with the design. What better way is there to create an API, than to learn from the mistakes and successes of other developers first ? Lets take a look at some examples in the java API where things could have been better…

Stack and Properties:

A java.util.Stack provides a standard Stack implementation in the java language. But did you know it extend a java.util.Vector ? Why is this wrong ? Because you can do this

package com.design;
 
import java.util.Stack;
import java.util.Vector;
 
public class StackTests
{
 
    public static void main(String... args)
    {
        new StackTests().go();
    }
 
    public void go()
    {
        Vector<String> vector = new Stack<String>();
        vector.add("first");
        Stack <String> stack = (Stack <String>) vector;
        String peek = stack.peek();
        System.out.println(peek);
 
        stack.push("next");
        stack.push("item");
        String remove = vector.remove(2);
        System.out.println("Removed: " + remove);
        peek = stack.peek();
        System.out.println(peek);
    }
}
 
Output:
 
first
Removed: item
next

There are so many things that are going on there that are wrong.

1. Vector is a slow DS. Its methods are synchronized and there is no way around this right now since this contract has been sealed. It cannot be changed without changing backward compatibility.

I chanced upon a post a while back about how a switch statement should be replaced with the strategy pattern. If you have not had a chance to go through it, please do. The post is not very long.  I found myself disagreeing very strongly with the author of the post and I was surprised to find that people thought this was a good idea.

The gist of the post was that using the Strategy pattern was better than using switch statements to determine which logic to execute. Here is why I think the idea used there was bad

1. The introduction of the Strategy pattern, in the example, introduces three new classes. So for every case in a switch statement, we should go about replacing the corresponding code with a new class ? This could easily lead to an explosion in the number of classes.

Iterators can be designed so that they are fail fast or fail safe. Depending on the underlying implementation of the Iterator, a ConcurrentModificationException is thrown if the Collection is modified while Iterating over the data structure. It pays to understand how an Iterator will behave under both conditions. Lets try to implement fail fast Vs fail safe iterators of our own.

Our data structure for this example is pretty simple. It defines an interface that abstracts set and get operations on a structure. How the underlying classes handle invalid set operations or the size of the structure is implementation dependent

A data structure interface:

public interface Data<T> extends Iterable<T>
{
    int size();
    T getElement(int position);
    void setElement(int position, T t);
}

An underlying implementation of such an Interface, could be say an array of Integers whose size is fixed. Invalid indexes on bounds are not allowed and the internal structure will not grow or shrink. An implementation is given below