Object-Oriented Programming Concepts

After the irritation of "Hello World!" is was a pleasure to start a thread with some substance.

I liked the description of objects, and analogy between the state and behaviour of real world objects and the fields and methods of software objects. The diagram was a bit weird. At first I thought there were 3 methods and 3 fields with methods on the left and objects on the right. But I guess displaying an abstract idea with a diagram is always tricky, and if you asked a hundred illustrators to do this they'd come up with a hundred ideas. I might have drawn it differently, but it focussed my thoughts and was still an asset to the thread.

I liked the bicycle analogy, especially when it was extended to the description of classes. But when the idea was converted to code, I found the methods disappointing. I guess because I like physics, in the apply brakes method, I was looking for something about forces, masses and coefficients of friction. I know it has to be kept simple, but these methods were too simple, to the point of being confusing.

If you think of a method as being like a mathematical function, in the function f(x) something always happens to x. For example:

f(x) = 2x
f(x) = x + 2
f(x) = x - 2

But in the tutorial, the change cadence method is more like:

f(x) = a

You don't need a function for this, and you don't need cadence method in the tutorial. Having it there doesn't add to the learners understanding of what a method is and does; it detracts from it. If all you are doing is assigning a value to a variable you can just assign it. To clarify what I mean, if one has previously created an object mybicycle from the bicycle class:

 cadence    =   myBicycle.changeCadence(newValue)

is tautologous gibberish, when you can do just as well with:

 cadence    =    newValue

Besides, I bet there are many people out there in the tutorial readership who don't know what a cadence is, especially those for whom English is not their first language. If anyone from Sun ever reads this, my advice would be to drop the changeCadence method, and either drop the changeGear method, or rewrite it as:

       void changeGear(int deltagear) {
      gear = gear + deltagear;      
     }

where deltagear can be positive or negative. It's still boring, but it's not completely redundant.