Tuesday, January 11, 2005

Object Bootcamp - day1

Fred started the session by asking the class to draw a pie chart based on the importance of the concepts of Polymorphism, Inheritance and Encapsulation to OOP. I came up with a figure of 45%Encapsulation, 30% Polymorphism and 25% Inheritance. Most of us were around the same percentages. Fred's opinion was 60% Encapsulation, 30% Polymorphism and 10% Inheritance. He also noted that in the early days, when OOP was introduced, high importance was placed on Inheritance.

He then gave a brief history of how OOP evolved. Initially, finding the right data structure was considered the most important thing to do. It was assumed that once the data structure is correctly identified, then writing a set of behaviors around it is essentially what OOP was all about.

Later Data hiding evolved to be the most important thing. Since changing a datastructure affected several behaviors in the above said method, this turned out to be the challenge. So it was important to hide the data and provide behaviors around it, this is also known as Encapsulation.

We then started to design a Rectangle Class. Fred says it is important to conceptualize for a good OO design. "Jobs" of a class needs to identified first. Every class must have one and only one job, and this should be understood to identify an object. Example of a good job for class Rectangle is: undertands a geometrical object with 4 sides with right angles at all the ends. Examples of bad jobs are ones that have circular reference, jobs that describes the data and jobs that go into implementation details.

When we design objects, we should think of them as having a conversation. Suppose a user of Rectangle class asks the rectangle for the length, the question that we should ask is why? what are you going to do with that. Probably calculate area. In that case, that behavior has to be present in the Rectangle class itself. This is the conversation.

According to Fred, any class whose name ends with "er" or "or" is a bad object and hence bad encapsulation. Also, Manager classes are like real world Manager, they take credit for what they dont do. ;)

Fred likes to see all classes begin with a comment that starts with "understands". Example:
// understands four sided geometrical figure with right angles at all the corners
class Rectangle {
...
}


For tests, usuall "ensures" seems to fit it.

// ensures that Rectangle works fine
class RectangleTest extends TestCase{
...
}


In OOP, the cycle that someone should usually follow is as below:

Task followed by Design, followed by cycles of Test and Code and then finally integrate before proceeding to another task. This cylce should be done as quickly as possible. Fred says this cycle should be over as early as 15 minutes. At the end of 15 minutes, he likes to see the Green bar. The design aspect of this cycle is falsely ignored as not agile/xp but actually is very much part of this cycle. Yes, there is no upfront design as in a traditional waterfall model, but still is an important step where objects are identified, although for a very negligible time period.

2 Comments:

At 6:00 PM, Blogger sundar said...

hi suresh
first let me thanks you for such a useful and understandable (by me) post. if i can understand it; it is very nicely explained.

the following comments are just my opinions. they maybe wrong in which case i will be very happy to be refuted or argued against.

as i understand it, polymorphism and inheritance implement the idea of encapsulation or encapsulation is an effect of polymorphism and inheritance. so it may not be very exact to compare the importance of the three qualitites as they are not peers.

as far as the concept of classes is concerened i guess more than understanding it might be said that a class should say "I Exist" where I can stand for Rectangle as in your example. understanding is also a pretty specific job which can be misused. this is only a finicky point.

15-min cycles??!! i have a long way to go before i reach this destination.

thanks again suresh for a beautiful post (as in "Paul Graham beautiful").

 
At 8:57 AM, Blogger suresh said...

Encapsulation is not a by-product of Inheritance/Polymorhism. In fact i can argue the other way around that Encapsulation yields Polymorphism/Inheritance. If you see my later post on Inheritance, you might agree that Inheritance is something that you should not design for, it is just discovered to remove duplication and make the code better.

I didnt quite understand what you meant by "I Exist" concept. But I would say that every class has a very specific job. If you want to reuse that class, it cannot be reused in a context outside of what the job says. For example, in the case of Rectangle class, the same class cannot be used for a Rectangle that is represented in terms of Cartisan points.

And thanks for your comments..

 

Post a Comment

<< Home