Evolution of OOP

The OOP (Object Oriented Programming) approach is most commonly used approach now a days. OOP is
being used for designing large and complex applications. Before OOP many programming approaches
existed which had many drawbacks.

These programming approaches have been passing through revolutionary phases just like computer
hardware. Initially for designing small and simple programs, the machine language was used. Next came
the Assembly Language which was used for designing larger programs. Both machine and Assembly
languages are machine dependent. Next came Procedural Programming Approach which enabled us to
write larger and hundred lines of code. Then in 1970, a new programming approach called Structured
Programming Approach was developed for designing medium sized programs. In 1980's the size of
programs kept increasing so a new approach known as OOP was invented.

1) Monolithic Programming Approach

2) Procedural Programming Approach

3) Structured Programming Approach

4) Object Oriented Programming Approach

Monolithic Programming Approach: In this approach, the program consists of sequence of statements
that modify data. All the statements of the program are Global throughout the whole program. The
program control is achieved through the use of jumps i.e. goto statements. In this approach, code is
duplicated each time because there is no support for the function. Data is not fully protected as it can be
accessed from any portion of the program. So this approach is useful for designing small and simple
programs. The programming languages like ASSEMBLY and BASIC follow this approach.

Procedural Programming Approach: This approach is top down approach. In this approach, a program is
divided into functions that perform a specific task. Data is global and all the functions can access the
global data. Program flow control is achieved through function calls and goto statements. This approach
avoids repetition of code which is the main drawback of Monolithic Approach. The basic drawback of
Procedural Programming Approach is that data is not secured because data is global and can be accessed
by any function. This approach is mainly used for medium sized applications. The programming
languages: FORTRAN and COBOL follow this approach.

Structured Programming Approach: The basic principal of structured programming approach is to divide
a program in functions and modules. The use of modules and functions makes the program more
comprehensible (understandable). It helps to write cleaner code and helps to maintain control over each
function. This approach gives importance to functions rather than data. It focuses on the development of
large software applications. The programming languages: PASCAL and C follow this approach.

Object Oriented Programming Approach: The OOP approach came into existence to remove the
drawback of conventional approaches. The basic principal of the OOP approach is to combine both data
and functions so that both can operate into a single unit. Such a unit is called an Object. This approach
secures data also. Now a days this approach is used mostly in applications. The programming languages:
C++ and JAVA follow this approach. Using this approach we can write any lengthy code.

OOPs Concepts in C++

Object oriented programming is a way of solving complex problems by breaking them into smaller
problems using objects. Before Object Oriented Programming (commonly referred as OOP), programs
were written in procedural language, they were nothing but a long list of instructions. On the other
hand, the OOP is all about creating objects that can interact with each other, this makes it easier to
develop programs in OOP as we can understand the relationship between them.

Object Oriented Programming(OOP)

In Object oriented programming we write programs using classes and objects utilising features of OOPs
such as abstraction, encapsulation, inheritance and polymorphism

Class and Objects

A class is like a blueprint of data member and functions and object is an instance of class. For example,
lets say we have a class Car which has data members (variables) such as speed, weight, price and
functions such as gearChange(), slowDown(), brake() etc. Now lets say I create a object of this class
named FordFigo which uses these data members and functions and give them its own values. Similarly
we can create as many objects as we want using the blueprint(class).

//Class name is Car

class Car

//Data members

char name[20];

int speed;

int weight;

public:

//Functions

void brake(){

void slowDown(){

};

int main()

//ford is an object

Car ford;

Abstraction

Abstraction is a process of hiding irrelevant details from user. For example, When you send an sms you
just type the message, select the contact and click send, the phone shows you that the message has
been sent, what actually happens in background when you click send is hidden from you as it is not
relevant to you.
Encapsulation

Encapsulation is a process of combining data and function into a single unit like capsule. This is to avoid
the access of private data members from outside the class. To achieve encapsulation, we make all data
members of class private and create public functions, using them we can get the values from these data
members or set the value to these data members.

Inheritance

Inheritance is a feature using which an object of child class acquires the properties of parent class.

#include <iostream>

using namespace std;

class ParentClass {

//data member

public:

int var1 =100;

};

class ChildClass: public ParentClass {

public:

int var2 = 500;

};

int main(void) {

ChildClass obj;

Now this object obj can use the properties (such as variable var1) of ParentClass.

Polymorphism
Function overloading and Operator overloading are examples of polymorphism. Polymorphism is a
feature using which an object behaves differently in different situation.

In function overloading we can have more than one function with same name but different numbers,
type or sequence of arguments.

Polymorphism Example

#include <iostream>

using namespace std;

class Sum {

public:

int add(int num1,int num2){

return num1 + num2;

int add(int num1, int num2, int num3){

return num1 + num2 + num3;

};

int main(void) {

//Object of class Sum

Sum obj;

//This will call the second add function

cout<<obj.add(10, 20, 30)<<endl;

//This will call the first add function

cout<<obj.add(11, 22);
 return 0;

Output:

60

33

OBJECT ORIENTED PARADIGM: Problem Solving in OO Paradigm

Object-oriented problem solving approach is very similar to the way a human solves daily problems. It
consists of identifying objects and how to use these objects in the correct sequence to solve the
problem. In other words, object-oriented problem solving can consist of designing objects whose
behavior solves a specific problem. A message to an object causes it to perform its operations and solve
its part of the problem.

The object-oriented problem solving approach, in general, can be divided into four steps. They are:

(1) Identify the problem,

(2) Identify the objects needed for the solution,

(3) Identify messages to be sent to the objects, and

(4) Create a sequence of messages to the objects that solve the problem.

Following is an example of solution to a simple problem using the four steps.

Example 1: Object-oriented Problem Solving Approach

Step 1: Problem Identification – Compute the sum of two numbers and print out the result.

Step 2: Object Identification – Identify objects needed to solve the problem.

Num1 – first number (object). Num2 – second number (object). Sum – result of the addition of the two
numbers (object).

Step 3: Message Identification – Messages needed to send to objects.

+ aNum – This is the message sent to the receiver object with an parameter aNum. The result of
this message is the value (a numeric object) of the total sum of the receiver object and aNum.
print – a message that displays the value of the receiver object.

Step 4: Object-message sequences – Following is the object-message sequence to solve the problem.

(Num1 + Num2)print

The message + with a parameter Num2 (an object), is sent to the object Num1. The result of this is an
object (Num1 + Num2), which is sent the message print. The parentheses are included to avoid any
ambiguity as to which message should be activated first.

Note: The sequence of Smalltalk evaluation is from left to right unless is specified by parentheses ( ). For
example:

2+3*4 is 20 while 2 +(3 * 4) is 14

Object-oriented design process

Object-oriented design is the process of planning a system of interacting objects for the purpose of
solving a software problem. It is one approach to software design.
Input (sources) for object-oriented design

The input for object-oriented design is provided by the output of object-oriented analysis. Realize that an
output artifact does not need to be completely developed to serve as input of object-oriented design;
analysis and design may occur in parallel, and in practice the results of one activity can feed the other in
a short feedback cycle through an iterative process. Both analysis and design can be performed
incrementally, and the artifacts can be continuously grown instead of completely developed in one shot.

Some typical input artifacts for object-oriented design are:

Conceptual model: The result of object-oriented analysis, it captures concepts in the problem domain.
The conceptual model is explicitly chosen to be independent of implementation details, such as
concurrency or data storage.

Use case: A description of sequences of events that, taken together, lead to a system doing something
useful. Each use case provides one or more scenarios that convey how the system should interact with
the users called actors to achieve a specific business goal or function. Use case actors may be end users
or other systems. In many circumstances use cases are further elaborated into use case diagrams. Use
case diagrams are used to identify the actor (users or other systems) and the processes they perform.

System sequence diagram: A system sequence diagrams (SSD) is a picture that shows, for a particular
scenario of a use case, the events that external actors generate, their order, and possible inter-system
events.

User interface documentations (if applicable): Document that shows and describes the look and feel of
the end product's user interface. It is not mandatory to have this, but it helps to visualize the end-
product and therefore helps the designer.

Relational data model (if applicable): A data model is an abstract model that describes how data is
represented and used. If an object database is not used, the relational data model should usually be
created before the design, since the strategy chosen for object-relational mapping is an output of the OO
design process. However, it is possible to develop the relational data model and the object-oriented
design artifacts in parallel, and the growth of an artifact can stimulate the refinement of other artifacts.

Object-oriented concepts

The five basic concepts of object-oriented design are the implementation level features that are built
into the programming language. These features are often referred to by these common names:
Object/Class: A tight coupling or association of data structures with the methods or functions that act on
the data. This is called a class, or object (an object is created based on a class). Each object serves a
separate function. It is defined by its properties, what it is and what it can do. An object can be part of a
class, which is a set of objects that are similar.

Information hiding: The ability to protect some components of the object from external entities. This is
realized by language keywords to enable a variable to be declared as private or protected to the owning
class.

Inheritance: The ability for a class to extend or override functionality of another class. The so-called
subclass has a whole section that is derived (inherited) from the superclass and then it has its own set of
functions and data.

Interface (object-oriented programming): The ability to defer the implementation of a method. The
ability to define the functions or methods signatures without implementing them.

Polymorphism (specifically, Subtyping): The ability to replace an object with its subobjects. The ability of
an object-variable to contain, not only that object, but also all of its subobjects.

Designing concepts

Defining objects, creating class diagram from conceptual diagram: Usually map entity to class.

Identifying attributes.

Use design patterns (if applicable): A design pattern is not a finished design, it is a description of a
solution to a common problem, in a context.[1] The main advantage of using a design pattern is that it
can be reused in multiple applications. It can also be thought of as a template for how to solve a problem
that can be used in many different situations and/or applications. Object-oriented design patterns
typically show relationships and interactions between classes or objects, without specifying the final
application classes or objects that are involved.

Define application framework (if applicable): Application framework is usually a set of libraries or classes
that are used to implement the standard structure of an application for a specific operating system. By
bundling a large amount of reusable code into a framework, much time is saved for the developer, since
he/she is saved the task of rewriting large amounts of standard code for each new application that is
developed.

Identify persistent objects/data (if applicable): Identify objects that have to last longer than a single
runtime of the application. If a relational database is used, design the object relation mapping.

Identify and define remote objects (if applicable).

Output (deliverables) of object-oriented design

Sequence diagram: Extend the system sequence diagram to add specific objects that handle the system
events.

A sequence diagram shows, as parallel vertical lines, different processes or objects that live
simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which
they occur.

Class diagram: A class diagram is a type of static structure UML diagram that describes the structure of a
system by showing the system's classes, their attributes, and the relationships between the classes. The
messages and classes identified through the development of the sequence diagrams can serve as input
to the automatic generation of the global class diagram of the system.

Some design principles and strategies

Dependency injection: The basic idea is that if an object depends upon having an instance of some other
object then the needed object is "injected" into the dependent object; for example, being passed a
database connection as an argument to the constructor instead of creating one internally.

Acyclic dependencies principle: The dependency graph of packages or components (the granularity
depends on the scope of work for one developer) should have no cycles. This is also referred to as having
a directed acyclic graph For example, package C depends on package B, which depends on package A. If
package A also depended on package C, then you would have a cycle.

Composite reuse principle: Favor polymorphic composition of objects over inheritance.