Object BootCamp - day3

We started the day with a question to Fred asking him why he chose Probability to design. In the sense that why not something more equivalent to real world. Fred replied that Probability is a very good example, because when anyone is asked to represent Probability in a code, most people eventually end up with a float or a double to represent it. Also, in yesterday's class most of us had spent a great deal of time in checking for nulls and boundary conditions. Fred suggested that this is a waste of time and that we should listen to users. Only when the user requests for boundary conditions should we actually put that in code.
Also, Fred suggested that there need be no null checks in code. If someone passed in null, he/she deserves a NullPointerException.

Bottomline was, as engineers we tend to overengineer rather simple situations. Do not write extra code than necessary.

Then we had a very interesting discussion about designing for change. Designing for change does not mean we need to design for reusability. Why bother about tomorrow? If a code can be changed today, and if it takes the same time later, we better postpone it. That itself is a gain. For a code to be easy to change, XP advocates four principles:
1. It Works
2. It Communicates
3. There is no duplication in it and
4. Fewest possible classes are present.

We had switched partners in the middle of the session yesterday as well as today. An observation from that was it is important that all members within the same team use almost the same set of tools and IDEs. It is better to have environments that are identical.

We continued with the Probability class and implemented "and" and "or" methods. Most of us implemented the or method as

Probability or(Probability other) {

    return this.value + other.value - and(other).value;

}

Fred suggested using the DeMorgan's theorem. So we ended up with a code like this:

// DeMorgans theorem states A || B = not( not(A) and not(B) )

Probability or(Probability other) {

    return this.not().and(other.not()).not();

}

The above code, though a bit confusing has another big advantage. It re-uses the existing code, therefore better tested.