what is a object?

I thought I’d put down some ideas here now and in the future about this. I’ve been meaning to put this down somewhere for a long time, so why not here.This is for people looking to understand object orientation in a light different from the traditional approach. Did you learn that object orientation is about encapsulation, data hiding, inheritance and polymorphism? Don’t believe a word they say. It isn’t true. At least not in the way they put it.

I’d like you to take a different approach to object orientated programming. Put away all your ideas of encapsulation and polymorphism. They will only hinder you now.

Think systems. Systems consist of entities having responsibilities, that interact with eachother for some purpose.

Now, think people.

In your department, each of member knows who your manager is. His name, where his desk is, what time he comes to the office, where he lives. I’m new to you company. I need talk to the manager of your team, but I don’t know him. I know you. I ask you who the manager is. You point him out to me. I talk to your manager. What just happened?

It is the responsibility of each member of the team to know who the manager is. So when I need to speak with your manager, I came to ask you.

Object orientation is an approach that models responsibilities and interaction of the components of a system.

Let us translate the above scenario into an object oriented model:

1. You, I and the manager are entities in the system. Correspondingly, you, I and the manager are represented by objects in the software model of the system. Each of your team members are also represented by their respective objects in the software model.

2. The team must consist of members. Correspondingly, the team object will be a container of some kind. It could be a list data structure, that has a set of reference variables pointing to each member of the team.

3. Each member is responsible for telling anyone who asks who his/her manager is. Correspondingly, each object representing members of the team has a reference variable that points to their manager’s object, and a “getter� method that returns this reference to the caller.

4. You are the only member of the team that I know. So correspondingly, my object has a reference variable pointing to your object.

Now I need to speak with the manager. How do I find out who the manager is? I must ask you to show me who your manager is.

In object oriented terms, my object calls a method of your object. The job of this method is to return the reference to your manager that you have. Then my object calls methods of the manager object as appropriate.

Let me now list the basic features of object orientation:

1. Object orientation is an approach to making a software model of a system.
2. All entities in the system are represented by objects.
3. Every object has responsibilities. These could range from providing information, to performing specific tasks.
4. Entities in the model should get their work done by asking the right object to perform one of it’s responsibilities. So object orientation models the interactions between objects.

This is a simplistic description, but approaching a problem in this way is the first step.

The system to be modeled may be a real world scenario such as the one I mentioned, or something as mechanical as parsing logs and processing the information in them. Both can be modeled using the object oriented approach.

Object orientation is not the ideal approach in all situations. I’ll say more on this later sometime. I think that you should keep yourself open to using different approaches for systems of different scales. The best way to do this is not to think in terms of objects and methods. Think in terms of entities, their responsibilities, and interactions between entities in a system. With a bit of practice, it’s easy to translate this into the object oriented idiom. More on other approaches to design later.