Wednesday, January 12, 2005

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.

3 Comments:

At 4:25 PM, Blogger sundar said...

i agree with almost everythign that you have said here.
but not this
"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."
can this be characterised as arrogance? i think one should be concerened about checking for illegal values being passed and those situations being handled in a graceful manner, and throwing a NPE is certainly not graceful.
am sure this is debatable, just my 0.02$ worth.

 
At 7:59 PM, Blogger saswat said...

As per Fred, the user of the class needs to be very explicit in his call for checking boundary
Values and for expected null values.
I am just wondering as of how to implement in a class.
What I feel is we are putting the same chunk of code in a different block rather than
Putting it in-line with the function’s statements.
By doing this what’s the benefits will be.

 
At 8:01 PM, Blogger saswat said...

As per Fred, the user of the class needs to be very explicit in his call for checking boundary
Values and for expected null values.
I am just wondering as of how to implement in a class.
What I feel is we are putting the same chunk of code in a different block rather than
Putting it in-line with the function’s statements.
By doing this what’s the benefits will be.

 

Post a Comment

<< Home