The imperative programming paradigm is the oldest and the most traditional one. It has grown from machine and assembler languages, whose main features reflect the John von Neumann’s principle of computer architecture. An imperative program consists of explicit commands and calls of procedures to be consequently executed; they carry out operations on data and modify the value of program variables, as well as external environment. Within this paradigm variables are considered as containers for data similar to memory cells of computer memory.
In the imperative paradigms we can think of a program as an active agent that manipulates passive objects. We encounter many passive objects in our daily life: a stone, a book, a lamp, and so on. A passive object cannot initiate an action by itself, but it can receive actions from active agents.
A program in a procedural paradigm is an active agent that uses passive objects that we refer to as data or data items. To manipulate a piece of data, the active agent issues an action, referred to as a procedure. For example, think of a program that prints the contents of a file. The file is a passive object. To print the file, the program uses a procedure, which we call print. The concept of the imperative paradigm
Imperative Paradigms is made up of three parts: a part for object creation, a set of procedure calls and a set of code for each procedure. Some procedures have already been defined in the language itself. By combining this code, the programmer can create new procedures.
Characteristics:
Discipline and idea
Digital hardware technology and ideas of Von Neumann
Incremental change of the program it state as a function of time.
Execution of computational steps in an order governed by control structures
We call the steps for command
Straightforward abstractions of the way a traditional Von Neumann computer works
Similar to descriptions of everyday routines, such as food recipes and car repairs
Typical commands offered by imperative languages
Assignment, IO, procedure calls
The natural abstraction is the procedure
Abstracts one or more actions to a procedure, which can be called as a single command.
“Procedural programming”
OBJECT-ORIENTED PARADIGM:
Object-Oriented Paradigm, a program describes the structure and behaviour of so called objects and classes of objects. An object encapsulates passive data and active operations on these data: it has a storage fixing its state and a set of methods describing behaviour of the object. Classes compose an inheritance hierarchy including polymorphism of operation. Execution of an object-oriented program is regarded as exchange of message between objects, modifying states.
Object-oriented paradigm deals with active objects instead of passive objects. We encounter many active objects in our daily life. The actions to be performed on these objects are included in the object: the objects need only to receive the appropriate stimulus from outside to perform one of the actions.
A file in an object-oriented paradigm can be packed with all the procedures called methods in the object-oriented paradigm to be performed by the file: printing, copying, deleting and so on. The program in this paradigm just sends the corresponding request to the object.
In object-oriented paradigm, objects of the same type (files, for example) need a set of methods that show how an object of this type reacts to stimuli from outside the object’s “territories”. To create these methods, a unit called a class is used
Characteristics:
Discipline and idea
The theory of concepts, and models of human interaction with real world phenomena
Data as well as operations are encapsulated in objects
Information hiding is used to protect internal properties of an object
Objects interact by means of message passing
A metaphor for applying an operation on an object
In most object-oriented languages objects are grouped in classes
Objects in classes are similar enough to allow programming of the classes, as opposed to programming of the individual objects
Classes represent concepts whereas objects represents phenomena
Classes are organized in inheritance hierarchies
Provides for class extension or specialization
Real-World Example using Imperative and Object-oriented Paradigms:
Let’s say that you are working for a vehicle parts manufacturer that needs to update its online inventory system. Your boss tells you to program two similar but separate forms for a website, one form that processes information about cars and one that does the same for trucks.
For cars, we will need to record the following information:
Colour, engine size, transmission type, number of doors
For bus, the information will be similar, but slightly different, we need:
Colour, engine size, transmission type, number of passengers
In Imperative programming, you would write the code first to process the car form and then the code for the truck form, but In Object-Oriented programming, you would write a base class called vehicle that would record the common characteristics what we need from both trucks and cars. In this case, the vehicle class will record:
Colour, engine size, transmission type
We’ll make each one of those characteristics into a separate method. The colour method, for example, could take the colour of the vehicle as a parameter and do something with it, like storing it in a database.
Next, we will create two more classes: truck and car, both of which will inherit all of the methods of the vehicle class and extend it with methods that are unique to them. The car class will have a method called numberofdoors and the truck class will have the methods numberofpassengers.
As you seen from above example , employing an object-oriented programming style has significant advantages over Imperative programming, especially as your scale increases, doesn’t mean that you should never use Imperative programming, if you’re doing a mock-up or a proof-of-concept app, you might not have time to make everything object-oriented and so I think it might would be better to use Imperative programming for a prototypes, but it would be best to make the production product in an Object-Oriented manner.
Conclusion:
Object-Oriented programming is the brain-child of imperative programming and would not exist without its parent. On that note, we would not have the large-scale, highly modular, highly powerful programming abilities that we have today without the growth of imperative procedural programming into what is now object-oriented programming.
Cite This Work
To export a reference to this article please select a referencing style below: