Object Oriented Programming

From APIDesign

This is my personal take on OOP. In case you are searching for objective view, then rather see official wikipedia's explanation.

Revolutionary view

Let me point you to an essay explaining OOP in completely revolutionary view. I especially like statements like:

• Typical object oriented program relies on functions more than many functional programs.
• λ-calculus was the first OOP language

Excellent explanation of the differences between OOP approach and the functional one can be summarized into:

• In classical OOP one only knows own identity. Identity (and implementation) of others can be inspected only by calling their methods (sending them messages)
• In functional world (when using algebraic types) the person that defines a type can inspect internals of all instances of the same type

The above characteristic of OOP leads to an interesting conclussion: OOP needs tail calls!

Last but not least the essay mentions the expression problem which I also analysed in TheAPIBook's chapter 18: Extensible Visitor Pattern Case Study.

Object Oriented Reuse

I always felt that there is some clash between the general desire for object oriented reuse and principles of good API design. Proponents of reuse seem to advocate making every method virtual, every class subclassable, every behavior changeable while exposing DeepHierarchy of inheritence. Those who maintained API of a framework for some time and tried to keep some degree of BackwardCompatibility know that opening up more than planned for will at the end hurt the reuse.

I attribute this to the way subclassing is done in Java or C++ or similar languages. For a long time I could not formulate that feeling, but I kept a thought back in my mind about an OOP language which is not flawed this way - Beta. However I never had enough time to learn Beta properly, I just read the specification. It felt somewhat down side up, but without practical experience it was hard to formulate exactly what was so attractive on this rotation.

That is why I am thankful to authors of Super and Inner — Together at Last! for explaining everything in the Java terminology and even finding ways to make these two worlds co-exist in piece. The paper also proposes new access modifier (which I called for in my ClarityOfAccessModifiers essay). It is named pubment and it is a perfectly fine (from API design perspective) combination of callable and slot which allows augmentation:

Code from SuperInner.java:

public abstract class JavaLikeExample {
  public final int callable() {
    return 1 + theSlot();
  }
 
  protected abstract int theSlot();
}
 

Code from SuperInner.java:

public abstract class BetaLikeExample {
  pubment int callable() {
    int res = inner.callable();
    return res + 1;
  }
}
 

The paper also explains why inner is more suitable for API design. To quote: The overall philosophy of class extension in Java-like languages (using super) is: subclass implementors know better. The philosophy of class extension in Beta-like languages (with inner) is: superclass implementors know better.

Regardless of using Java or Beta style and with the hope to support cluelessness of our API users I want to recommend: When designing an API, always make sure that you know better than users of your API!

History

OOP is no longer what it used to be. Somehow the original great visions diluted and instead we have class/object/inheritance as present in Java and other OOP languages of these days. The daily experience we have with these languages is so strong, so defining that we sometimes tend to forget that the roots of OOP used to be driven by visions and not technical concepts.

I was reminded about that recently when I read DCI introduction paper at artima website. Just few quotes:

Object oriented programming grew out as vision of the computer

as an extension of the human mind.

Wow! Really? Makes sense, but this is a piece of wisdom lost for a long time, am I right? Even when I learned about OOP I heard more the explanation describing the methodology as inspired by nature. The inheritance was the most natural way to define base class Mammal and subclasses Cat and Dog.

Our brain can definitely capture more complex concepts than the mammal example, so maybe, if we want to stick with the old definition, the meaning of OOP shall be expanded. Definitely beyond the expressive capabilities of C++ and Java.

MVC's goal was to provide the illusion of a direct connection

from the end user brain to the computer "brain"

a large method that represented an entire algorithm was believed to

not be a "pure" object-oriented design

This use of inheritance crept out of the world of programming

language into the vernacular of design