The art of Object-Oriented Programming (OOP)

When you discuss software engineering with people involved in a software project they will generally tell you that they are programming in an object oriented manner. Why? Because they use an OO language (Java, C#, etc). The fact that the language is OO generally leads them to believe that simply using objects means that all their development immediately follows the OO paradigm. My opinion is that OOP isn’t achieved only by using an appropriate language. It’s much more than that!

OOP basically is about modularity.


Splitting up a program not only in functions, but at a higher level in objects. These objects can be grouped in packages, components and subsystems. So modularity is used on different levels of abstraction. This components or subsystems can also be used as building blocks for other systems. Nowadays we see this being used to give components and (sub)systems web interfaces, using them as building blocks in a SOA (Service Oriented Architecture). I will address this topic in future posts.

But, back to OOP. Grouping functions and data into objects is a creative process. You always have to decide about functions in the ‘grey-area’. It is a challenge to have a strict separation of responsibility among the objects in your system. A very simple example of what is going wrong often is given other objects full access to data in an object. How can this object have the responsibility of this data when it can’t control the access to this data? Another situation people doesn’t often think a lot of is grouping objects into packages. This can be very powerful in lowering the complexity of a system. But you have too think thoroughly about which objects should be grouped into which package. Also the use of the façade pattern can be helpful in this situation.

An object on it’s own can also be an ‘object of study’. Think about the state and the behaviour of an object and how the methods (functions) affects these. A nice article on this topic is “Five Habits of Highly Profitable Software Developers” by Robert J. Miller (read article). He presents five habits which can help software developers keeping their software maintainable and of high quality in a team environment.

To end this post I will state the following heuristic (see first post): “Choose the elements so that they are as independent as possible; that is, elements with low external complexity (low coupling) and high internal complexity (high cohesion). (Christopher Alexander, 1964 modified by Jeff Gold, 1991).

3 Comments Added

Join Discussion
  1. Michiel October 21, 2006 | Reply

    OOP basically is about modularity.
    I tend to think that OOP is more about abstraction, encapsulation and hiding. In other words, discouraging developers from writing logic in the wrong place. This is a huge advantage and architecturally enforces the ‘do everything once and only where it’s supposed to be done’ attitude. Naturally it’s still possible to completely bypass this in any OO environment, but it does take more effort (or really bad design). It also makes testing easier as well as exporting APIs to any number of environments.
    The massive, yet modular, systems such as the linux kernel show us that coding discipline can create a modular environment without using OO.

  2. Johan den Haan October 26, 2006 | Reply

    Michiel, thanks for the comment. I think you are right that abstraction, encapsulation and hiding are important keywords in OOP. These techniques make it easier to have a strict modularity in your system and in this way they support the basic idea of OOP: modularity. You can of course use modularity in non-OO languages. But OOP has a lot of constructions which can help you doing this easier. The main idea in developing the early OO languages was to make modularity more easy and therefor a lot of techniques are build in, like the ones you already mentioned.

  3. Jewel July 24, 2007 | Reply

    Modularity is a very abstract idea and not sufficient to describe the objective of OOP. Yes, OOP let us modularize the stuffs but many things also allow us to do that at their respective level, like, you can write a modular program in C separating the task efficiently in different function, you can also separate the related data to some extends using “struct” but you can’t relate those data and most importantly hide that relationship using C. Here comes the role of OOP.
    In a nutshell OOP let us reduce the complexity through allowing us breaking down the big system into subsystems. The word “system” is important here. A function alone is not a system, a group of data alone is not a system. The minimum requirement of being a system is ability to hold the related data and operation in it. OOP let us think in this way as you know, the example of these minimum size of system is object in OOP. Collection of objects in a package is also a system and so on…

Leave a Reply to Johan den Haan Cancel reply