Well, there seems to be at least some interest in object design topics, judging by the positive reactions I received on my last techfile entry. Therefore, I’ll talk about this a bit more. First of all, here’s an example I encountered in real life which indicates one advantage of encapsulation (Which I talked about in my previous entry).
I wanted to keep track of the values of an array of booleans in what we call an inspection dialogue. In order to do this, the routine “UpdateDialogue” has to be called each time one of the array-elements is changed. Now, if the class had been nicely encapsulated, this array would be accessible only through a “Set….” function. This means the only place where I would have had to add the “UpdateDialogue” call was in that particulair set-function. Unfortunately, the array was a public member, accessed by other classes directly. This meant a complex, error-prone find/replace action was needed to update the 300+ places where the array was accessed.
I repeat here that in my view encapsulation is the most important aspect of OOP. Without it, class-reuse and the concepts of inheritance and polymorphism come to nothing.
Which brings me to the remaining two fundamental concepts of OOP, you guessed it: Inheritance and polymorphism. Probably all of you are familiar with inheritance, so I won’t explain it here. Polymorphism is less well known, and trickier to explain. Time for a classic example:
Now you know a bit about OOP on a practical level, I think next time I will tell you something about high-level design patterns. Traditionally, a design pattern is defined as “A solution to a problem in a context”, which is quite an infuriating definition in my view. I’ll try to make it clearer next time.
As final words, the three building blocks of OOP are linked nicely by the following statement:
By using the mechanism of inheritance, and applying the concept of encapsulation, the goal of polymorphism is achieved.
Download The Sample Program: ManicMotion.exe