Object-Orientation is not Really About Objects

How do we write good object-oriented programs? Despite the name, it is not by focusing on objects.

OrientationObject-oriented (OO) programming presents several concepts to the programmer not present in a procedural language. Given the name “object-orientation”, objects is clearly a central concept. Objects are the basic building blocks of our program and they carry out all the important work of our program. This should be contrasted with procedural programs, where functions are global and data is passed as arguments.

From time to time, you come across OO programs that has a procedural flavor to them. There are few, if any, interfaces and classes are primarily used to organize related functions with data. Admittedly, this is a slight administrative improvement over procedural programming with structs and global functions. The problem is, OO programs like this have the same problems as procedural programs: coupling.

Martin Fowler illustrates the concept very well in his article Design Principles and
Design Patterns
(Figure 2-17 on page 13). Assume you have a main function. Main calls three other functions, which in turn calls two other functions. Main now depends on all its descendants! High-level logic should not depend on low-level implementation.

The same applies to the “procedural style OO program” described above. Main might use three objects and call a function in each. Those functions might call two functions on some other classes and so forth. Main will depend on all classes and functions. Before you know it, main depends on your whole system.

The point is, even though objects do all the important work, they do not take us very far when trying to write good, decoupled software. Instead, have a look at Figure 2-18 in the article. Assume that main calls functions on three different interfaces. Main would not know or care which class implements each interface. Main depends only on the interfaces.

Thus, when writing object-oriented software, think primarily about abstractions and interfaces. After that, you can think about objects.

3 thoughts on “Object-Orientation is not Really About Objects

  1. Without neglecting the value of depending on abstract interfaces, I must say that I do not totally agree that introducing abstract interfaces makes the architecture much more object oriented if that is what you claim. A system designed using algorithmic decomposition, but where all dependencies are against abstract interfaces will suffer from much the same problems as a corresponding design without abstract interfaces for those relations. In most cases, types which are naturally polymorphic does typically not come from a system designed using algorithmic decomposition. With just a focus on reducing dependencies on concrete classes, one will probably just arrive at abstract classes with just one derived class. Sure that can simplify testing by enabling mocking, but that is an orthogonal issue in my opinion. The type is non-polymorphic as far as the architecture in concerned.

    In Advanced C++ Idioms, James Coplien wrote “If you can not think of two good, significantly different implementations of an entity, then a broader abstraction is probably needed.” I guess that creating an abstract interface ought to make the programmer automatically think in that way. However, I have seen abstract interfaces severely restricting plausible alternative implementations (also bad without abstract interface, because it makes it hard to rewrite the class). In that case it buys you little more than the Pimpl idiom.

    In my opinion, all established methods of design have a focus on abstractions, what is different is where the focus of abstraction is and the view taken when coming up with the abstractions. Object Oriented Analysis and Design with Applications 3ed says: “The algorithmic view highlights the ordering of events, and the object-oriented view emphasizes the agents that either cause action or are the subjects on which these operations act.”

    • Hi Magnus,

      Thank you for your comments!

      I am merely saying that tight coupling between the parts of our software is a bad thing (in any programming language). And that we achieve decoupling in object-oriented programs through the use of interfaces. And that procedural-style OO is missing out the benefits of OOP. Thus the central role of interfaces (not only for decoupling, but for most OO concepts and design principles).

      We both agree that an interface can lead to abstraction (when the interface hide details of the domain) and can be used for polymorphism. But in the scenario above, we use an interface to obtain dependency inversion.

      See you! / Johnny

      • Hi Johnny,

        We agree. I like your other post about that: “Design Principles by Example: Talk to an Interface or an Abstraction?

        See you! / Magnus

Leave a Reply

Your email address will not be published.