Why OO Programming?

What is Programming?
Programming is a way of giving instructions to computers for doing something.

Question: How do we give instructions to computers? How do we communicate with

computers?

Answer: Writing programs, using programming languages. Could be machine, assembly or

high level languages like C, C++, Java, etc.

Let’s see how we came to a point of using the OOP paradigm, starting from the early efforts
for coping with complexity of programs: Unstructured Programming, Structured
Programming and Object Oriented Programming.

Unstructured Programming
Before 1970s, the only programming paradigm was unstructured programming. With that
paradigm, all branching (?) was done using GOTO. Assembly language, Fortran, and BASIC are
perfect examples of unstructured programming.

An unstructured program might look like this:

The use of branch instructions like GOTO and

GOSUB gave rise to the term "Spaghetti
Code", so called because a flowchart (?) could
become as convoluted and twisted as a plate of
spaghetti. As program size increased, defect
rates skyrocketed.

Let’s think of a program with 55 pages without

a single line break, not a single subroutine
(function – method) - just 55 pages of non-stop
spaghetti! And, would it work? May be yes or
could anyone understand it? Or, how could you
maintain (change and debug) a program like
this.

1
 Ultimately, tool vendors responded by
adopting structured methods. For example,
Microsoft Visual Basic.

Structured Programming

➢ Structures in Codes

In the 60’s and 70's, two fundamental structures are identified in coding:

▪ Decision Blocks
▪ Loops

Programming languages like Pascal implemented the concept of structured programming. A

structured language has constructs like:

▪ IF-THEN-ELSE and WHILE-NEXT

▪ SWITCH-CASE
▪ DO-WHILE
▪ FOR-NEXT

➢ Functional Decomposition

Within the efforts of trying to solve the complexity of the programs and trying to design better
programs, functional decomposition was the another approach.

This approach (functional decomposition) to program design was based on the following advice:

▪ To solve a large problem, break the problem into several pieces and work on each piece
separately;
▪ to solve each piece, treat it as a new problem which can itself be broken down into
smaller problems;
▪ eventually, you will work your way down to problems that can be solved directly,
without further decomposition.

2
This approach is also called top-down design.

For example, one can decompose the

types of operations needed for a word
processor, such as:

▪ editing,
▪ selecting fonts,
▪ printing,
▪ saving to file,
▪ etc.

A software manager might also use

Functional Decomposition to delegate
major tasks among various
programmers.

Functional Decomposition and using structures in codes (if, while, for statements) was the primary
points of Structured Programming.

Examples of languages that support the structured programming paradigm:

FORTRAN C, C++, Java, Ruby, PHP, JavaScript, Python, Pascal, ColdFusion and
COBOL.

With structured programming, software engineers realized that data was overlooked and
reusing programs for other projects was cumbersome.

Data Overlooked

There is nothing wrong with top-down approach. It is a valuable and often-used approach to
problem-solving. However, it is incomplete:

▪ it deals almost entirely with producing the instructions necessary to solve a problem.
▪ (But as time went on, people realized that) the design of the data structures for a
program was as least as important as the design of subroutines and control structures.
Top-down approach doesn't give adequate consideration to the data that the program
manipulates.

3
Reusability Issue

Another problem with strict top-down approach is that is makes it difficult to reuse work done
for other projects.

By starting with a particular problem and subdividing it into convenient pieces, top-down
approach tends to produce a design that is unique to that problem.

It is unlikely that you will be able to take a large chunk of programming from another program
and fit it into your project, at least not without extensive modification. Producing high-quality
programs is difficult and expensive, so programmers and the people who employ them are
always eager to reuse past work.

Top-down Combined with Bottom-up

So, in practice, top-down design is often combined with bottom-up design. Engineers started
using previous solutions in other projects.

In bottom-up design, the approach is to start "at the bottom," with problems that you already
know how to solve (and for which you might already have a reusable software component at
hand). From there, you can work upwards towards a solution to the overall problem.

As an example, a mailing subsystem is mainly used in all projects. Why develop it over and
over in all projects.

4
Modularity

The reusable components should be as "modular" as possible.

A module is a component of a larger system that interacts with the rest of the system in a
simple, well-defined, straightforward manner.

The idea is that a module can be "plugged into" a system. The details of what goes on inside
the module are not important to the system as a whole, as long as the module fulfills its
assigned role correctly. This is called information hiding, and it is one of the most important
principles of software engineering.

One common format for software modules is to contain some data, along with some subroutines
for manipulating that data.

For example, a mailing-list module might contain:

▪ a list of names and addresses (data)

▪ along with a subroutine for adding a new name, a subroutine for printing mailing
labels (code), and so forth.

In such modules, the data itself is often hidden inside the module; a program that uses the
module can then manipulate the data only indirectly, by calling the subroutines provided by the
module. This protects the data, since it can only be manipulated in known, well-defined ways.
And it makes it easier for programs to use the module, since they don't have to worry about

5
the details of how the data is represented. Information about the representation of the data is
hidden.

Information Hiding Principle → OOP

Modules that could support this kind of information-hiding became common in programming
languages in the early 1980s. Since then, a more advanced form of the same idea has more or
less taken over software engineering. This latest approach is called object-oriented
programming, often abbreviated as OOP.

Object Oriented Programming

The central concept of object-oriented programming is the object. In OOP programming, all
the program components are represented as objects. An object binds the data and the
associated methods together as single unit. The programmer can control the data access
permissions by defining the access specifier.

Object: A kind of module containing data and subroutines. A (kind of) self-sufficient entity;

▪ that has an internal state (the data it contains)

▪ can respond to messages (calls to its subroutines).

6
 For example: A mailing list object,
▪ Has a state:
o consisting of a list of names and addresses.

▪ Can respond to messages:

o If you send it a message telling it to add a name, it will respond by modifying
its state to reflect the change.
o If you send it a message telling it to print itself, it will respond by printing out
its list of names and addresses.

The OOP approach to software engineering is to start by identifying;

▪ the objects involved in a problem and

▪ the messages that those objects should respond to.

The program that results is a collection of objects, each with

▪ its own data

▪ its own set of responsibilities

The objects interact by sending messages to each other (calling their subroutines).

There is not much "top-down" in such a program, and people used to more traditional programs
can have a hard time getting used to OOP.

However, people who use OOP would claim that object-oriented programs tend to be better
models of the way the world itself works, and that they are therefore easier to write, easier to
understand, and more likely to be correct.

7
Overview of OOP Principles
The fundamental object-oriented principles.

Encapsulation

Encapsulation is the mechanism of hiding of data implementation by restricting access to public

methods. Instance variables are kept private and accessor methods are made public to achieve
this.

For example, we are hiding the name and dob attributes of person class in the below code
snippet.

Encapsulation — private instance variable and public accessor methods.

public class Employee {

private String name;
private Date dob;

public String getName() {

return name;
}

8
 public void setName(String name) {
this.name = name;
}

public Date getDob() {

return dob;
}

public void setDob(Date dob) {

this.dob = dob;
}
}

Abstraction

Abstract means a concept or an Idea which is not associated with any particular instance. Using
abstract class/Interface we express the intent of the class rather than the actual
implementation. In a way, one class should not know the inner details of another in order to
use it, just knowing the interfaces should be good enough. It allows the developer to consider
the complex ideas and ignores the irrelevant details.

Inheritance

It is a mechanism where you can derive a class from another class for a hierarchy of classes
that share a set of attributes and methods. It explains how the class hierarchies develop
code readability and support to the reuse of functionality.

Inheritances expresses “is-a” relationship between two objects. Using Inheritance, In derived
classes we can reuse the code of existing super classes. In Java, concept of “is-a” is based on
class inheritance (using extends) or interface implementation (using implements).

For example, FileInputStream "is-a" InputStream that reads from a file.

9
Polymorphism

It means one name many forms. It is further of two types — static and dynamic. Static
polymorphism is achieved using method overloading and dynamic polymorphism using
method overriding. It is closely related to inheritance. We can write a code that works on
the superclass, and it will work with any subclass type as well. Polymorphism is the process of
using same method name by multiple classes and redefines methods for the derived classes.

Benefits of object-oriented programming approach:

• Better abstraction
• Better maintainability
• Better reusability

10