Object BootCamp - day4

Yesterday i had written about how to refactor the "or" method in Probability class to use existing methods. The day started with a question on that. What if we had started with the "or" method? Fred suggested that either we could have written down the "and" and "not" methods as private, or could have very well settled for the first version. At a later time, when the "not" and "and" methods are written, we could refactor the "or" method to reuse the other methods.

Fred then observed that there was a difference between object thinking and traditional thinking. Object thinking tries to find groups of behaviours to find objects, traditional thinking tries to group data together. He also gave an interesting anology of churning of objects. He said we should churn objects and they in turn communicate and churn out objects.

What followed next was a discussion on equals method. Fred gave us a template for writing equals method. The first step should be to check if both instances are same. The second step should be a check for null. Then the type of the objects should be compared. Note that we should use the getClass to compare the type instead of the instanceof operator. Reason is that instanceof operator returns true even for subclasses, which is not desirable for equals method. Finally the actual comparison for equality of two instances of the same type should be done, probably in a private/protected method.

In summary, the steps to write an effective equals method are:
1. if( this == other ) return true;
2. if( other == null ) return false;
3. if( this.getClass() != other.getClass() ) return false; // can use instanceof when class is final.
4. return equals( (Probability) other ); // a private/protected method to do the actual check.

We then had a discussion about the various relations that two objects can have. Essentially, there are four types of relations: a "buy" relation( composition relation ), aggregation, inheritance and collaboration. A buy relation seems to be the favorite with Fred and he would like to see a cascading chain of such relation. There should be no cycles of relations and backward pointer. Both of these are code smells.

Fred then gave us a more real world problem to design. He wanted us to represent relations like 1 quart = 4 cups.
Take a moment and think about a solution, its really interesting.

I came up with a design as below:

// understands the quantity of anything in terms of a standard unit of measurement

class Measure {

    private final double quantity;

    private final UOM unitOfMeasure;

}

I was not quite sure about how UOM class should look like and what its job would be. At the end of the session, the below representation seemed to be the best that we were able to come up with. I still believe the factor could also be represented in terms of objects. Let me think...

// understands a standard measurement unit

class UOM{

    public static final UOM QUART = new UOM("Quart", 1);

    public static final UOM CUPS = new UOM("Cups", 2);



    private final String name;

    private final double factor;

    private UOM(String name, double factor) {

        ...

    }

}