What Is Object-Oriented Development?

The traditional view of a computer program is that of :

a process that has been encoded in a form that can be executed on a computer. 

This view originated from the fact that the first computers were developed mainly to automate a well-defined process (i.e. an algorithm) for numerical computation, and dates back to the first stored-program computers.

Accordingly, the software creation process was seen as a translation from a description in some ‘natural’ language to a sequence of operations that could be
executed on a computer.
As many would argue, this paradigm is still the best way to introduce the notion of programming to a beginner, but as systems became more complex, its effectiveness in developing solutions became suspect. This change of perspective on part of the software developers happened over a period of time and was
fueled by several factors including the high cost of development and the constant efforts to find uses for software in new domains.

One could safely argue that the software applications developed in later years had two differentiating characteristics:

• Behaviour that was hard to characterize as a process
• Requirements of reliability, performance, and cost that the original developers did not face

The ‘process-centered’ approach to software development used what is called top-down functional decomposition.

1. The first step in such a design was to recognize what the process had to deliver (in terms of input and output of the program), which 
2. was followed by decomposition of the process into functional modules. 
3. Structures to store data were defined and the computation was carried out by invoking the modules, which performed some computation on the stored data elements.

The life of a process-centred design was short because changes to the process specification (something relatively uncommon with numerical algorithms when compared with business applications) required a change in the entire program. This in turn resulted in an inability to reuse existing code without considerable overhead.
As a result, software designers began to scrutinize their own approaches and also study design processes and principles that were being employed by engineers in other disciplines. Cross-pollination of ideas from other engineering disciplines started soon after, and the disciplines of ‘software design’ and ‘software engineering’ came into existence.

In this connection, it is interesting to note the process used for designing simple
electromechanical systems.
For several decades now, it has been fairly easy for people with limited knowledge of engineering principles to design and put together simple systems in their backyards and garages. So much so, it has become a hobby that even a 10 years old could pursue. The reasons for this success are easy to see:

• easily understandable designs, 
• similar (standard) solutions for a host of problems, 
• an easily accessible and well-defined ‘library’ of ‘building-blocks’,
• interchangeability of components across systems, 
• ... and so on.

Some of the pioneers in the field of software design began to ask whether they could not also design software using such ‘off-the-shelf’ components.

The object-oriented paradigm, one could argue, has really evolved in response to this outlook. 

There are, of course, several differences with the hardware design process (inevitable, because the nature of software is fundamentally different from hardware), but parallels can be drawn between many of the defining characteristics of hardware design and what today’s advocates of good software
design recommend.
This methodology, provides us with:

1. a step-by-step process for software design, 
2. a language to specify the output from each step of the process so that we can transition smoothly from one stage to the next, 
3. the ability to reuse earlier designs, standard solutions that adhere to well-reasoned design principles and, 
4. even the ability to incrementally fix a poordesign without breaking the system.

The overall philosophy here is to define a software system as a collection of objects of various types that interact with each other through well-defined interfaces.

Unlike a hardware component, a software object can be designed to handle multiple functions and can therefore participate in several processes. A software component is also capable of storing data, which adds another dimension of complexity to the process.

The manner in which all of this has departed from the traditional process-oriented view is that

1. instead of implementing an entire process end-to-end and defining the needed data structures along the way, we first analyze the entire set of processes and from this identify the necessary software components. 
2. Each component represents a data abstraction and is designed to store information along with procedures to manipulate the same. 
3. The execution of the original processes is then broken down into several steps, each of which can be logically assigned to one of the software components. 
4. The components can also communicate with each other as needed to complete the process