As a developer the focus will be on to quickly complete the task at hand and any developer would wish everything worked perfect the first time. The focus will be to implement the logic that is in mind and the ones that will be left out are things like,

a. Comments/Documentation
b. Essential log information
c. Unit Test code
d. Proper error and exception handling (for example handling the generic Exception in java is not a good practice)

There could be more to the list. But the point here is that it is too tempting for a developer to just make the program work and postpone the above as anyone seeing the output will not know whether the above points were taken care of or not. But the above help in code readability, maintainability and quality of the program and are equally important as the program’s output. Procrastination to the last minute can be costly as even the above could induce human errors and it can lead all the way to a problem in production. The best way to make sure the above points are covered is to have self discipline and follow the standards and best practices in the first place. As a developer when you estimate and give a time line include all the necessary tasks that include the above and any other points so that you don’t need to postpone them to a later time.

Few days back I had posted about use case. Use case diagrams are the starting point to a good UML design and the better it captures the actors, use cases, relationships it is easy to translate it further to other UML design artifacts that can be translated into a good object oriented code. I tailgated some links to get to this article on “Creating Use Case Diagrams” in Developer.com. It’s a good starting point for any business analyst who wants to start with use cases for a project.

Matt Weisfeld author of “Object Oriented Thought Process” has been posting a series in developer.com based on excerpts taken from his book.  Object thinking is very important as most of us today are claiming that we are object oriented developers but how far are we really doing object oriented programming is questionable.  Understanding Object oriented concepts are easy if they can be properly correlated with our interaction with objects in the real time world. Matt Weisfeld has beautifully done that in this book with good examples and is a definitive guide to any developer who sincerely wants to learn and apply the object oriented programming concepts in the true sense.

My other posts on Object Thinking.

The first rule that you need to follow before you dive deep into OOP, is to fist understand how objects work in the real world. Lets go through it again. What is the definition of an object? I mean a physical object in the real world, say you might have learnt or could refer books or get the definition from net. I am sure you would find the words attribute, behavior, characteristics, operations and related words wherever you search for. Lets go by that definition first. Here is a simple definition that I pulled out from the result of a google “define:object search”.

In object-oriented design or programming, a concrete realization of a class that consists of data and the operations associated with that data.

If you had seen my post titled “Object Thinking - Thinking Objects”, you would have realized that these attributes and behavior are well defined and has a definitive scope (remember you cannot light a gas stove using a vessel or cup). But think about this, a well defined object is as equivalent to a stone sitting in the north pole. Every object needs a message to act. Yes you heard it right, objects can hear and act just like how you would when somebody talks to you. You act upon the objects by passing a message.

Take the same coffee example, just by keeping all the objects around, you wont get coffee, come on be serious. Remember the chain reaction, yes you started it and was there to pass on the message whenever and wherever required. So what happens when you pass on a message, the object reacts and changes its state (a state is value change in the object’s attribute). You strike the match stick against the match box and bingo there you have the flame, so the match stick’s state changed from being just a match stick to a match stick with its head on flame. Flame is passed on to the gas stove, the heat message is passed on to the vessel and it passes it to the milk, result is the milk’s temperature state changes. Wow, isn’t that cool? Did you ever think about it?

So aren’t we missing something drastic from the definition of an object to just being attribute and character/behavior. Let’s redefine it. An object is a well defined set of attributes with behavior or characteristics with the ability to react to a message and change its state. How does that sound? Now start looking at all the exercises you did in collecting objects and scenarious from the “Object Thinking - Thinking Objects” post exercise and analyze them, what message is passed and what state gets changed in each object.

The first step to Object thinking would be to think about the objects. From the beginning the key aim in developing a programming language is to make it as humane as possible. And as each programming language was developed, we came closer and closer until we realized that we are missing out a big picture to imitate our lifestyle of interacting with objects. Just think about a moment in your day. Try counting the number of objects you interacted in that moment. OOP is all about creating programs with objects that interact with each other like the way we interact with objects and objects with each other. Let us take a simple example of preparing a coffee. For any problem we have to limit the scope, so here we assume we have the necesary things and environment to prepare coffee.

Step 1: Take a vessel and fill it with a cup of milk
Step 2: Light on a match stick
Step 3: Switch on the gas stove and light it using the fire from step 2
Step 4: Keep the vessel on stove
Step 5: When the milk in the vessel starts to boil switch off the gas stove.
Step 6: Put a spoon of sugar in a cup
Step 7: Put a spoon of coffee powder in the cup
Step 8: Add the boiled milk to the cup
Step 9: Stir the mixture in the cup well with the spoon.

Ofcourse the preparation method and type of coffee could vary depending on the taste and type you are used to. You could also elaborate and keep abstracting the above steps (for example before step 6 you could say take the sugar jar and take a spoon full and so on), but be practical and if you keep abstracting you will lose focus on the problem. The idea here is to think about the objects involved in the above steps and identify its purpose. So lets list a few.

Vessel - a container to hold anything in limited quantity, used to cook
Cup - a container to hold anything in limited quantity, used basicaly to temporarily store and transfer
Match stick - stick that can be ignited to bring a flame.

Ok you could argue with me on the purpose descriptions above, but you are right whatever you describe as the purpose as far as you are clear with what you know as the purpose of that object. Now if you see in the above steps you can also see that there is a chain of reaction that happens between the objects with the outcome, you holding a cup of coffee. So it is not just objects but the interaction between objects and you and objects that’s making this world go around. But more than just understanding object interaction, a critical point is the purpose of the object is well defined and does not work beyond its purpose. For example you cannot bring the gas stove to flame with a vessel or a cup. The second important point is you have to use the objects in the right way specific to the problem you are addressing to make use of it effectively. For example if you try to keep the vessel upside down over the gas stove, the vessel doesn’t care but it does not solve your problem.

The next step to the above exercise is that you can think about object interactions and the sequence. This is one simple exercise that you could keep working on as many times in a day. Try thinking about the sequence of steps and the objects involved and their interaction next time when you sit before your TV and switch to another channel using the remote. You dont need to write it down or sit before your computer to do it, your mind is the notepad and brain is the processor, use them effectively and you are the master.

Ask this question to yourself if you are working on a project that uses a object oriented language. Is your project and your program’s object oriented? If you think that if you have written classes in your project and hence it is Object Oriented then you are terribly wrong. There is lot more to object orientedness than what most of us think. The true essence of Object Orientedness comes from the key characteristics that you might have learnt about in any OOP (Object Oriented Programming) book. Here is the link to a neat article in Java Developers Journal.

“Are You Using Abstract Classes, Polymorphism, and Interfaces? If the answer is no, at a minimum your project needs a code review.”

Object Thinking is a habit that any programmer should cultivate, it should be there in your mind always, cross checking your code. The essence of object orientedness is more than what is mentioned in the article above. More on this later.

The first question I ask in any interview is what do you think is the difference between Object and Class. Most of the time I get the bookish answer that an object is an instance of class and class is a blueprint. Ofcourse the answer is right, but when I ask the candidate to forget about any programming language or technology and give me an example for a class and corresponding object from the real world, he/she most of the time tells me an example that always fits as example for class.

For example this is a common example that the candidates give. An example for a class would be Car and the corresponding object would be Maruti (an Indian car model). Think about this, how can Maruti be an instance of the Car class when Maruti by itself is a bluprint of a type of Car or in object oriented terms, Maruti inherits Car but is still a class. What really would be an object for the class car would be to really show a car that is running on the street or parked outside. Because that is real instance, that you can feel, get into and drive.

That’s Object Thinking foundation #1.