We have a very simple assignment:
Lets say we want to calculate a distance formula for traveling from one place to another. The distance formula has to include all the attributes of the journey. So let us see what data do we have-
Variables:
Location: Have to go from one city to another (both the cities can be anywhere
in the world).
Modes of travel: Car/Bus/Train
Date constraints: Departure/Arrival Date.
Time Preference: Morning/Afternoon /Evening
Distance: Break Journey
Travel Cost. Etc
Now, we have termed these data items as “variables” because their value would be changing based upon the various choices made. Even for such a trivial problem, there are being so many options/constraints,there are so many approaches to arrive at a decision. On similar lines, given a problem and basic resources (which also act as constraints), various algorithms can do the task programmatically. An algorithm is nothing but the thought process/approach involved.
A good approach should
- Be generic so that it works well with all possible combinations of inputs.
- Flexible / adaptable to absorb new inputs. (New destination, routes, rates,
timings or even new mode of travel - say space travel) - Give solutions in the desired time frame.
- Make best use of resources available. (Optimize the solution)
- Cost effective.
- Simple enough.
Primitively, there was a very straightforward manner to write applications. Straightforward in the sense that the various tasks in the application would be identified and would be automated. This approach did work for many scenarios but when it came to the robustness or maintenance of the application, this approach proved to be insufficient.
In this section we will first discuss what was the procedural approach and how the design of an application be made using this approach. By trying to figure out the negative points in the approach we will then appreciate the advantages of object oriented programming by discussing it as a solution to overcome the shortcomings of procedural programming.
Concept of Procedural Programming
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.
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:
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:
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.
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.
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.
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.
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
Inheritance
What is common between a father and a son? At least one thing would be common – their assets!
In real life, inheritance allows us to reuse things that belong to a particular entity. Also, in object oriented world a class can inherit the properties and functionalities defined in some another class so that they can be reused. Then we have to be a bit careful in designing these classes because reusability cannot be done unless the classes are of the same type. So the class which would be reusing the functionalities of the other class in object oriented terms we would say that the class is “deriving” from the former class and is termed as the derived class. The class that is being “derived from” is termed as the base class.Inheritance directly results in the following benefits:
Reusability: Inheritance results in functionalities defined in one class being reused in the derived classes. So the efforts of rewriting the same functionality for every derived class is being saved. This definitely saves a lot of development time.
Enhancement and Specification: Due to the characteristic of inheritance, we can club the common functionalities in the base class and have the specific functionalities in the derived class. This feature can be used to have a functionality defined in the base class to be further modified for betterment or specification by the derived class. This mechanism of redefining the functionality of the base class in the derived class is termed as “overriding”
Avoiding type inspection: In the case study that we discussed to understand procedural approach we had a strict type inspection routine at the library end wherein in every function in the library we had to check for the type of the employee for whom the work has to be done. With inheritance, we would have a common base class called as “Employee” which would have all the common functionalities defined where as the specific routines do be done for various types of employees would go in the respective derived classes. So there would be class defined for every type of employee and the class would all the specifications for that type of employee and would be derived from the base class Employee to inherit the common functionalities. Therefore, in the functions now we wont have to check for the type of employee every time because every employee type has its own specific routines defined within it.
Polymorphism
The word “polymorphism” means “different forms”. Applied in object-oriented paradigm it means the ability of an entity to exhibit different forms at runtime.
However, why would such a kind of feature be required? One major reason to have this is to eliminate the type inspection. As we can see in the earlier case study that we discussed there would also be a type inspection checking at the client application level where in the employee entities would be used. So just as in every functionality, we had checked for the type of employee we will also have to check in the main function about the type of employee we are handling. With polymorphism, we can have this level of type inspection also being eradicated totally.
How does .NET support object oriented programming?
As we have discussed in the earlier sections .NET happens a to be a “complete framework”. The basic approach adopted by the framework is object-oriented and the framework would support only object-oriented code. So no more C and COBOL applications! Although C++ and OO-COBOL would work perfectly fine.
Since the framework is inherently object-oriented everything i.e. every data type in the framework will be a class. Unlike C++, even the primitive data types will be given by the framework as a set of classes.
The framework also provides us with a rich set of classes which can be used by instantiating them or writing new classes by deriving from the framework classes. The framework does have a systematic organization of classes wherein the Object class from the System namespace (we will discuss namespaces in details later) tops the chart. All the other classes are derived from the Object class.
Component Oriented Programming
However, is it really enough just to have an object oriented approach? Well, now with the increasing influence of the web and code reusability getting extended across the language barriers its very much essential to even extend “Object Oriented approach “ itself.
We need to extend the definition of the “class” which happens to be the basic element of object oriented programming. We know that the class serves as an abstraction or simulation of a real life entity. However, in order to have a total encapsulation the internals of the class has to be totally hidden. Secondly, the class should be instantiable across various programming languages to have a more range of reusability. The class should ideally support properties (will be discussed a little later) to offer more user friendliness and overcoming the incompatibilities.
Therefore, a class must have the following extra abilities in addition to what it serves in object-oriented scenario:
Understanding C# and VB.NET as Object Oriented Programming languages
After knowing the object-oriented concepts let us examine how these concepts can be implemented in CSharp (C#) or VB.NET. These two languages are been introduced along with the .NET framework and are totally .NET compliant. So VB.NET will be a natural upgrade for VB programmers and CSharp for C++ programmers. We will be looking at the various syntaxes of both these languages to implement object oriented programming.
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.
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.
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.
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.
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
Inheritance
What is common between a father and a son? At least one thing would be common – their assets!
In real life, inheritance allows us to reuse things that belong to a particular entity. Also, in object oriented world a class can inherit the properties and functionalities defined in some another class so that they can be reused. Then we have to be a bit careful in designing these classes because reusability cannot be done unless the classes are of the same type. So the class which would be reusing the functionalities of the other class in object oriented terms we would say that the class is “deriving” from the former class and is termed as the derived class. The class that is being “derived from” is termed as the base class.Inheritance directly results in the following benefits:
Reusability: Inheritance results in functionalities defined in one class being reused in the derived classes. So the efforts of rewriting the same functionality for every derived class is being saved. This definitely saves a lot of development time.
Enhancement and Specification: Due to the characteristic of inheritance, we can club the common functionalities in the base class and have the specific functionalities in the derived class. This feature can be used to have a functionality defined in the base class to be further modified for betterment or specification by the derived class. This mechanism of redefining the functionality of the base class in the derived class is termed as “overriding”
Avoiding type inspection: In the case study that we discussed to understand procedural approach we had a strict type inspection routine at the library end wherein in every function in the library we had to check for the type of the employee for whom the work has to be done. With inheritance, we would have a common base class called as “Employee” which would have all the common functionalities defined where as the specific routines do be done for various types of employees would go in the respective derived classes. So there would be class defined for every type of employee and the class would all the specifications for that type of employee and would be derived from the base class Employee to inherit the common functionalities. Therefore, in the functions now we wont have to check for the type of employee every time because every employee type has its own specific routines defined within it.
Polymorphism
The word “polymorphism” means “different forms”. Applied in object-oriented paradigm it means the ability of an entity to exhibit different forms at runtime.
However, why would such a kind of feature be required? One major reason to have this is to eliminate the type inspection. As we can see in the earlier case study that we discussed there would also be a type inspection checking at the client application level where in the employee entities would be used. So just as in every functionality, we had checked for the type of employee we will also have to check in the main function about the type of employee we are handling. With polymorphism, we can have this level of type inspection also being eradicated totally.
How does .NET support object oriented programming?
As we have discussed in the earlier sections .NET happens a to be a “complete framework”. The basic approach adopted by the framework is object-oriented and the framework would support only object-oriented code. So no more C and COBOL applications! Although C++ and OO-COBOL would work perfectly fine.
Since the framework is inherently object-oriented everything i.e. every data type in the framework will be a class. Unlike C++, even the primitive data types will be given by the framework as a set of classes.
The framework also provides us with a rich set of classes which can be used by instantiating them or writing new classes by deriving from the framework classes. The framework does have a systematic organization of classes wherein the Object class from the System namespace (we will discuss namespaces in details later) tops the chart. All the other classes are derived from the Object class.
Component Oriented Programming
However, is it really enough just to have an object oriented approach? Well, now with the increasing influence of the web and code reusability getting extended across the language barriers its very much essential to even extend “Object Oriented approach “ itself.
We need to extend the definition of the “class” which happens to be the basic element of object oriented programming. We know that the class serves as an abstraction or simulation of a real life entity. However, in order to have a total encapsulation the internals of the class has to be totally hidden. Secondly, the class should be instantiable across various programming languages to have a more range of reusability. The class should ideally support properties (will be discussed a little later) to offer more user friendliness and overcoming the incompatibilities.
Therefore, a class must have the following extra abilities in addition to what it serves in object-oriented scenario:
- Encapsulated data and implementations
- Properties
- Language Interoperable
Understanding C# and VB.NET as Object Oriented Programming languages
After knowing the object-oriented concepts let us examine how these concepts can be implemented in CSharp (C#) or VB.NET. These two languages are been introduced along with the .NET framework and are totally .NET compliant. So VB.NET will be a natural upgrade for VB programmers and CSharp for C++ programmers. We will be looking at the various syntaxes of both these languages to implement object oriented programming.