Does your software/web application gain the benefits of Object Orientation (OO)? Well designed object-oriented applications exhibit high cohesion and low coupling. Small changes to requirements mean small changes to the code. Just because you use an OO language like Java,C#, C++ etc. does not mean your application benefits from object-orientation.

A number of years ago I collaborated with a really good C programmer. (Don’t worry I will not mention any names.) We were asked to test the suitability of an OO language called Modsim II. I had already been programming/thinking OO for a few years. My colleague had not. We decided on an application that would:

  1. Ask a user for things they wanted to simulate

  2. Query a database for those things

  3. Show a graphic representation of the requested things in a simulation to the user.

We decided to split the app into two pieces. My friend would take the front-end user interface aspects. I would program the back-end interface with the database. We worked separately for a couple of weeks on our respective parts of the code. When we got back together we showed each other our software and discussed what we had learned about programming in the OO language.

I was first up. At the time there was no such thing as Hibernate. I had to build the interface between the OO world and the RDBMS world myself. I built the equivalent of Value Objects, a Database Session Manager, and a low level interface object. My friend looked carefully at all these objects and was surprised to discover that my objects did not seem to do anything. There was no single method that pulled everything together. And yet, as a group of objects working together they got the job of generating SQL, retrieving data, and creating the right objects for her software to use in the front-end. She was beginning to realize that this OO form of programming was quite different than the C programming she was used to.

Next my colleague described her objects. There were four defined classes. At runtime there were four object instance – one for each class. Each object was responsible for groups of complex data structures defined as attributes. My friend had solved the problem as if she were writing in C. The C functions turned into complex methods on a class and the C data structures turned into attributes in to class that had methods using those structures. The classes were not cohesive. Each class tried to do too much.

Feeling just a little mischievous, I asked my friend what would happen to these four classes if the data type of one of the attributes had to change? I pointed out a specific attribute that I knew would have to change. It turned out that most of the code had to be rewritten. Then I showed my colleague that I would only have to change one attribute in one super class and a couple of methods to effect the change. That was the benefit of high cohesion, low coupling, and information hiding / encapsulation provided by the Object Oriented approach I brought to programming.

For the next few weeks we worked together to improve the application. My colleague’s code became object-oriented with much better cohesion and lower coupling. What about your application? Perhaps I can help you as I have done for thousands of others.