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.