C++ programming

Course Code : BCS-031

                                                       Course Title : Programming in C++

Question 1:

(a) Explain why Object Oriented Programming approach is better than Structured

Programming Approach.

Structured Programming versus Object-Oriented Programming

Software engineering is a discipline that is concerned with the construction of robust and

reliable computer programs. Just as civil engineers will use tried and tested methods for the

construction of buildings, software engineers will use accepted methods for analysing a

problem to be solved, a blueprint or plan for the design of the solution and a construction

method that minimises the risk of error. The discipline has evolved as the use of computers

has spread. In particular, it has tackled issues that have arisen as a result of some catastrophic

failures of software projects involving teams of programmers writing thousands of lines of

program code. Just as civil engineers have learned from their failures so have software

engineers.

A particular method or family of methods that a software engineer might use to solve a

problem is known as a methodology. During the 1970s and into the 80s, the primary

software engineering methodology was structured programming. The structured

programming approach to program design was based on the following method:

n To solve a large problem, break the problem into several pieces and work on each piece

separately;

n to solve each piece, treat it as a new problem that can itself be broken down into smaller

problems;

n repeat the process with each new piece until each can be solved directly, without further

decomposition.

This approach is also called top-down program design.

The following is a simple example of the structured programming approach to problem

solving.

Write a program for a computer to execute to display the average of two numbers entered

through a keyboard connected to the computer. The average is to be displayed on a VDU that

is also connected to this computer.

The top-down solution is arrived at as follows:

Top level: 0. Display average of two numbers entered through keyboard

Next level: 0.1. Get two numbers through keyboard

0.2. Calculate average of these two numbers

0.3. Display average on VDU

The three steps in next level can now be coded in a programming language such as

Pascal.1Top-down program design is a useful and often-used approach to problem solving.

However, it has limitations:

n It focuses almost entirely on producing the instructions necessary to solve a problem.

The design of the data structures is an activity that is just as important but is largely

outside of the scope of top-down design.

n It is difficult to reuse work done for other projects. By starting with a particular problem

and subdividing it into convenient pieces, top-down program design tends to produce a

design that is unique to that problem. Adapting a piece of programming from another

project usually involves a lot of effort and time.

n Some problems by their very nature do not fit the model that top-down program design is

based upon. Their solution cannot be expressed easily in a particular sequence of

instructions. When the order in which instructions are to be executed cannot be

determined in advance, easily, a different approach is required.

Top-down design was therefore combined with bottom-up design. In bottom-up design, the

approach is to start “at the bottom”, with problems that have already been solved and for

which a reusable software component might exist. From this position, the software engineer

works upwards towards a solution to the overall problem.

It is important in this approach that the reusable components are as “modular” as possible.

A module is a component of a larger system that interacts with the rest of the system in

a simple and well-defined manner.

The idea is that a module can be “plugged into” a system. The details of what goes on inside

a module are not important to the system as a whole, only that the module fulfils its function

correctly. For example, a module might contain procedures to print a list of students, to add a

new student, edit a student‟s details and to return a list of specified students. How the module

stores the master records of student details is hidden from applications/systems that use this

module. Similarly, the detail of how the various procedures are coded is also hidden. This is

called information hiding. It is one of the most important principles of software engineering.

Applications only require knowledge of what procedures are available from the module and

the data that can be accessed. This information is published. It is often called the module?s

interface or interfaces.

A common format for a software module is a module containing some data, along with some

subroutines (subprograms/procedures/functions) for manipulating that data. The data itself is

often hidden from view inside the module forcing a program using the module to manipulate

the data indirectly, by calling the subroutines provided by the module for this purpose. The

advantages of this approach are as follows:

n the data is protected, since it can be manipulated only in known, well-defined ways;

n it is easier to write programs to use a module because the details of how the data is

represented and stored need not be known;

n the storage structure of the data and the code for the subroutines in a module may be

altered without affecting programs that make use of the module as long as the published

interfaces and the module‟s functionality remain the same.

Modules that could support this kind of information-hiding became common in programming

languages in the early 1980s. The concept has been developed since then into a central

platform of software engineering called object-oriented programming, often abbreviated as

OOP.

The central concept of object-oriented programming is the object, which is a kind of module

containing data and subroutines. An object is a kind of self-sufficient entity that has an

internal state (the data it contains) and that can respond to messages (calls to its

subroutines). A student-records object, for example, has a state consisting of the details of all

registered students. If a message is sent to it telling it to add the details of a new student, it

will respond by modifying its state to reflect the change. If a message is sent telling it to print

itself, it will respond by printing out a list of details of all registered students.

The OOP approach to software engineering is to begin by

n identifying the objects involved in a problem;

n identifying the messages that those objects should respond to.

The solution that results is a collection of objects, each with its own data and its own set of

responsibilities. The objects interact by sending messages to each other.

There is not much “top-down” in such an approach. People used to the structured

programming approach find OOP hard at first. However, people who have mastered OOP

claim that object-oriented programs tend to be better models of the way the world itself

works. They claim that this produces solutions that are

n easier to write

n easier to understand

n contain fewer errors

Why is the object-oriented approach considered to be better at modelling the way the world

itself works? Consider the following exchange between two people:

First person: Jack, are you hungry?

Second Person: Yes I am, Jill.

Classifying this exchange in object-oriented terms, there are two messages flying between

two objects. The objects are Jack and Jill. The messages are “are you hungry?” and “yes I

am”. Jack knows how to respond to the message he receives. His set of responses might be

[Yes I am, No I am not]. Jack chooses the appropriate response by examining his internal

state, i.e. the contents of his stomach.

Objects are created knowing how to respond to certain messages. Different objects might

respond to the same message in different ways. If Jack is a robot, the response to the message

“Jack, are you hungry?” might be “that is a silly question, I do not have human

characteristics”. This property of objects – that different objects can respond to the same

message in different ways – is called polymorphism.

Another important concept in object-oriented programming is the concept of a class.

It is quite common for objects to belong to the same family. These are objects that contain the

same type of data and that respond to the same messages in the same way. Such objects are

said to all belong to the same class. In programming terms, a class is created and then one or

more objects are created using that class as a template. For example, the clock family consists

of devices that keep track of the passage of time. When their internal state changes they

update a display consisting of hours, minutes and possibly seconds. The only message that a

member of the clock family might know how to respond to is one that tells it to reset its

internal state to some hour and minute. There are many clocks in existence – clock objects.

They all belong to the clock family or class.

The classification of all clocks into one big family called the clock class is an

oversimplification. We can divide the clock class into two subclasses called analogue

display clocks and digital display clocks. They are related but differ in the way that they

display time.

Both subclasses have inherited the basic behaviour and characteristics of clocks but each has

its own way of displaying time. A subclass of a class is said to inherit the behaviour and

characteristics of that class. The subclass can add to its inheritance and can even “override”

part of that inheritance by defining a different response to some message that is known to the

parent class.

Inheritance is a powerful programming tool. It also supports the reuse of software

components. A class is the ultimate reusable component. It can be reused directly if it fits

exactly into a new program that is being constructed. If it nearly fits, it can still be reused, by

defining a subclass and then making the necessary changes in the subclass to make it fit

exactly.

A good illustration of class hierarchies – class, subclass, sub-subclass, et cetera – is a simple

drawing program that lets its user draw lines, rectangles, polygons and curves in one

thickness of brush on a screen. Each visible object on the screen could be represented in

software by an object in the program. There would be four classes of objects in the program,

one for each type of visible object that can be drawn. All the lines would belong to one class,

all the rectangles to another class, and so on.

What is the relationship between these classes?

All of these classes represent “drawing objects”. They would all know how to respond to a

“draw yourself” message.

What is the relationship between the classes line and rectangle?

Lines and rectangles need only two points to specify them - a line its two end-points and a

rectangle its top-left and its bottom-right corners.

What is the relationship between the classes polygon and curve?

Both classes represent multiple-point objects.

We can now see that there is a hierarchy of classes belonging to the simple drawing program.

Two-Point Object and Multiple-Point Object are subclasses of the class Drawing Object. The

classes Line and Rectangle are subclasses of the subclass Two-Point Object. The classes

Polygon and Curve are subclasses of the subclass Multiple-Point Object. The class

relationships can be shown on an inheritance diagram - see Figure 2 on the next page.