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.
6.2 Object Oriented Programming
Now with the major shortcomings of procedural programming let us look at how a different approach would help us. As mentioned earlier it is necessary to
concentrate more upon the entities in the application and not only upon the tasks done by the application.
Based upon this bottom line we have a certain set of rules defined as object- oriented paradigm. If a programming language satisfies these rules i.e. provides
certain features or keywords to implement these rules it would be qualified as an object oriented programming language.
Lets discuss the major conventions for object-oriented programming.
6.3 Classes
One of the major problems in the earlier approach was also the data and the functions working upon the data being separate. This leads to the necessity of
checking the type of data before operating upon the data. The first rule of the object-oriented paradigm says that if the data and the functions acting upon the
data can go together let them be together. We can define this unit, which contains the data and its functions together as a class. A class can also be
defined as a programmatic representation of an entity and the behavior of that entity can be represented by the functions in the class. In our earlier case study
the employee, can be represented as a class. A class will contain its data into various variables, which would be termed as data members and the behavior of
the class, which will be encapsulated, as functions will be termed as member functions.
6.4 Encapsulation
Many a times when we use certain tools, we hardly pay attention to the details about the functionality of the tool. We hardly pay attention to the various other
units, which make up the tool. This behavior to ignore unwanted details of an entity is termed as abstraction.
Now if the details are unwanted why show them to the user? Therefore, the creator might attempt to hide these unwanted details. This behavior is termed as
encapsulation. So we can say that encapsulation is an implementation of abstraction. Encapsulation directly leads to two main advantages:
Data Hiding: -- The user of the class does not come to know about the internals of the class. Hence, the user never comes to know about the exact data
members in the class. The user interacts with the data members only through the various member functions provided by the class.
Data Security: - Since the data, members are not directly available to the user directly but are available only through the member functions a validity check can
always be imposed to ensure that only valid data is been inserted into the class. So a Date class, which contains individual data members for storing date, month
and year, will have it ensured the month is never 13 or the date is never exceeding 31.
6.5 Inheritance
