Email I wrote in 2007 - I like the hard work spirit I had

Email wrote in 2007

Sent: Tuesday, September 25, 2007 10:22 AM
To: iSiva Team Zissou

Hi, folks, 

  I like to share some thoughts about maintenance of our Siva legacy code and new feature development. 

  20% bugs I fixed is related to Run Time Type Checking Exception. If we are good at code style, we can 
  avoid it in less than 10 minutes. But if we troubleshooting or expand the feature, it takes hours or even a day. 

  Through Catalina export file project recently, I found some tips to save time, for example, abstract the function 
  or class, use instanceof to discuss runtime type to avoid cast exception, it saves a lot of time in the late time 
  of project. Because report or export file, it is just SQL query or some account calculation.

  Abstraction saves time to avoid handling detail except SQL query itself, and runtime type discussion saves time to 
  debug and fix run time bugs.   

  But today I like to share the book I read yesterday.  The book is called the Elements of Java Style. And I used 
  several examples in the book to illustrate the ideas, and I also welcome you to give me feedback how you work 
  smartly on the areas like Run time type checking etc, and have some discussion with me  Java code experience, 
  have a nice day. 

Type Safety: 

1.       Wrap general-purpose classes that operate on java.lang.Object to provide static type checking 

Ensure type safety by wrapping a general class that barters in Object types with one that casts objects to a specific type. 
The following code shows how to wrap a general-purpose queue to create a type-specific one: 

      public class Queue {
            public void enqueue(Object object) {...};
            public Object dequeue() {...};
      }     

      public class OrderQueue {
            private Queue queue;           

            public OrderQueue () {
                  this. queue = new Queue();
            }           

            public void enqueue (Order order) {
                  this. queue.enqueue(order);
            }           

            public Order dequeue() {
                  return (Order) this. queue.dequeue();
            }
      }

2.       Encapsulate enumerations as classes. 

   Encapsulate enumerations as classes to provide type-safe comparisons of enumerator values:  

public class Color {

   private static int count = 0;
   public static final Color RED = new Color( count++);

   public static final Color GREEN = new Color( count++);

   public static final Color BLUE = new Color( count++); 

   private int value;  

   private Color( int value){
         this. value = value;
   }  

   public boolean equals (Color other){
         return this. value==other. value;
   }  

   public static int Color.count(){
         return count;
   }  

   Color aColor = Color.RED;  

   if(anotherColor.equals(aColor)){
         ...
   }
} 

Some other discussions: 

Exception:

 1. Only convert exceptions to add information
3.       Do not silently absorb a run-time or error exception 

Breaking this rule makes code hear to debug because information is lost: 

                 try{

               for( int i = v.size();--i>=0;){
                     ostream.println(v.elementAt(i));
               }
         }

         catch (ArrayOutOfBounds e) {
               //Oops! we should never get here...
               // ... but if we do, nobody will ever know!
         }

Other discussion which are good for developer to have discussion:

  Use polymorphism instead of instanceof.
  Program contract
  Construction

  81. Do not call nonfinal methods from within a constructor.