The whole core of procedural programming lies in deriving a straightforward sequential step-by-step guide to do a particular task. Let us understand this by analyzing a case study.
Lets take up a classic Payroll application that deals with various types of specifications for different employees. Lets say that this application is developed in one of the best procedural languages – C.
So, the “Employee” in the application will be represented by a structure, which will contain all the Employee attributes as data members of the structure. Assume that the application deals with three types of employees – Clerk, Manager and Marketing executive. All the employees do have some common
attributes and certain specific allowances (lets not talk of deductions!). The clerk gets medical allowance, the executive gets the traveling allowance and the manager gets house rent allowance and dearness allowance. Our Employee structure might look something like this:
struct Employee
{
int Id;
char Name[25];
char *Address;
char Designation[20];
double Basic;
float Med_Allow;
float Tra_Allow;
float HRA;
float DA;
}
The application would have functions, which would act upon the data, and do the necessary functionalities. So there would be at least following functions apart from others:
void AddDetails() ; // To add details of the
// employee to the structure
void PrintDetails() ; // To print the details of a
// particular Employee
double CalcSalary(); // To calculate the salary of a
// employee
This also could have been done having three different structures one for each Employee type but this would increase the overhead in programming in the functions and there would be a requirement of declaring three different arrays; one to store all clerk variables, one for manager variables and one for executive.
So let us have a common structure, which would suite all the employee types.
If we try to figure out the central algorithm of every function it would be quite monotonous wherein every function would have a strict type inspection routine to check the type of Employee every time. Because the functionalities differ for every type of Employee.
void CalcSalary ()
{
switch(EMP_TYPE)
{
case CLERK:
// All the CLERK specific calculations
case MANAGER:
// All the MANAGER specific calculations
case EXECUTIVE:
// All the EXECUTIVE specific calculations
}
}
This kind of type inspection will be featuring in every function, which would be dependant upon the type of the Employee.
Now, if we have to add a new Employee type to this application, which has its own specification about, the allowances received try to figure out the changes that we will have to do in the current case study. Not only will the Employee structure have to be modified but also even the functions have to be changed in order to accommodate the new Employee type. So just as we are currently having a case statement to correspond to one employee type, we will have to introduce one more case statement corresponding to the new employee type. In addition, while calculating the salary we might introduce some local variables in the function to do the necessary calculations. There is a probability that the new additions may lead to certain bugs being introduced in the current “working” code. So let us list down the various problems we would face in this application:
Maintenance: -- If the application has to support some change in the existing business logic for a particular employee type there might be more problems introduced since it is the same function that would be called for the different employee types.
Enhancement: -- When the application has to be enhanced further to add a new type of employee there would be changes made in all the functions, which depend upon the type of employee. Hence enhancing an application further would be quite hectic. Why only new type of employee? Even if have to add a little more functionality to an existing function it would prove quite cryptic.
Extensibility: -- The current design of the application does not allow us to have extensibility easily. Therefore, if we have to add more functions, which would do certain tasks for all the employee types or maybe for some of the type of employees; the new function also will have a strict type inspection routine to
check for the type of employee.
Storage: -- A small but significant problem. Whenever we have the data saved in a persistent storage i.e. having the data into files on the hard disk we will have to take care of saving the data along with the appropriate type of the employee. Also, while reading the data from the file its necessary to read the type first and then accordingly initialize the members in the structure.
If we try to look for the core problem in the application design which can be qualified as a cause for all the problems discussed above it definitely would be an attempt to design a common algorithm to suit all the types of employees. It would definitely prove helpful if rather than concentrating on the procedures we concentrate more upon the entities in the application.