What is an Object?

Objects are key point in understanding OOP, under this programming paradigm a software Object represents a real world object. Take some time to look around and you will see many of them, you will have a monitor in front of you, a mouse, a keyboard a desk and so on. Real world objects and software Objects have two characteristics: state and behavior. A dog object (in OOP everything is an object even persons so please no hard feelings!!) might have the following state: name, color, breed, hungry and the following behavior: barking, fetching, wagging tail.

Real world objects vary in complexity for example a lamp might have just two states on and off and two possible behaviors turnOn and turnOff. However, a television might have additional states such as: on, off, currentChannel, currentVolume and behavior: turnOn, turnOff, increaseVolume, decreaseVolume, scanChannel. It is important to notice that some objects might also contain other objects. The world of OOP tries to model real objects into software objects by observing states and behaviors.

A software Object stores its state in fields which are the variables in many programming languages and executes behavior through methods which are functions in many programming languages as well. Methods tipically manipulate the object's internal state and interact with other objects. Hiding internal state and forcing all object's interaction with other objects through methods is also known as data encapsulation a fundamental concept of Object-oriented Programming.

Let's identify a Bicycle software object. First let's think about the state, in this case a Bicycle could have the following ones: current gear, current pedal cadence, current speed. Now let's think about its behavior: changing gear, changing pedal cadence, applying brakes. Having identified our Bicycle software Object we could graphically represent this Bicycle in OOP as the following picture

In this example we can see how data encapsulation is implemented, in this particular case by attributing state (current speed, current pedal cadence, and current gear) and providing methods for changing that state, the object remains in control of how the outside world is allowed to use it. For example, if the bicycle only has 6 gears, a method to change gears could reject any value that is less than 1 or greater than 6.

We can identify the following benefits when using objects:

• Modularity: The source code of a particular object can be kept independently from other object's source code. Making the code easier to write, maintain and test. Once the object is created can be easily transferred across the system without the need to recreate it.
  

• Information-hiding: By making usage only of the objects methods, the details of its implementation can be hidden from the outside world. This is a nice advantage so other objects attempting to interact with the Bicycle object won't be able to break its functionality.

• Code re-use: If an object already exists (perhaps written by another software developer), you can use that object in your program. This allows to implement/test/debug complex, task-specific objects, which you can then trust to run in your own code.
  

• Pluggability and debugging ease: If a particular object turns out to be problematic, you can simply remove it from your application and plug in a different object as its replacement.