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).