The History Of Object Oriented Paradigm

Published Date: 02 Nov 2017

The scope of this study is to prove whether it would be more efficient, if programmers had to go back to developing applications using the Procedural method, rather than the Object-Oriented method.

In order to prove this hypothesis, two websites have been created. One of these was created using the Procedural Method while in the second the Object-Oriented Method was used.

During website development and thereafter, Software Quality Metrics were used in order to determine a number of characteristics about each website. These include: the size, performance, and complexity.

INCLUDE SECTION OF RESULTS AND WHAT WAS CONCLUDED FROM THEM!

Introduction

Throughout my course over the last five years, I have always strived to develop the most efficient applications possible using my skills. However, not all applications were as efficient as I expected them to be. After assuring myself that the code I wrote was highly efficient, I shifted my attention to the style that I was using in order to program.

I asked myself: "Is this lack of efficiency in any way linked to the style I am using?"

This led me to begin researching my question – If a programmer is given a certain type of program (large or small) to develop, which paradigm would be better to use? The Procedural paradigm, or the Object-Oriented paradigm?

It is a well-known fact that programming, throughout the years, has evolved continuously. The same can be said for the style a programmer uses to program. This style has changed from an unstructured, Procedural way, to a structured, Object-Oriented format.

My research will focus on the Procedural, and Object-Oriented programming approaches. Following this, Software Quality Metrics will be used to determine which of these two, is superior.

Literature Review

1.1 Programming Paradigms

A Programming Paradigm is the structure which a programmer uses in order to build up the application. The main programming paradigm used is the Object-Oriented Paradigm, which developed from the Procedural Paradigm.

However, these are not the only two paradigms that exist. There are other paradigms in use, such as the Functional Paradigm, and the Logic Paradigm. These paradigms were created over a period spanning more than 40 years.

A number of programming techniques were detailed by themselves within each paradigm, creating a different scope for where they can be applied.

1.1.1 Procedural Paradigm

The procedural paradigm is concerned with defining a linear procedure or sequence of programming statements. A key feature of the paradigm is the partitioning of functionality into small discrete re-usable modules called procedures (subroutines or functions) that act like small programs themselves with their own scope, inputs and outputs. Programming languages that are used for the procedural paradigm include Pascal and PHP.

Procedural Programming is one of the first styles thought to new programmers. It serves two key roles: to provide programmers with a solid grasp of programming and prepare them for future challenges.

The Procedural Paradigm has a very long history, dating back to the 1950’s. Since then, programming language designers saw that assignment commands and variables created a simple, but highly useful abstraction, from the memory fetch and update of machine instruction sets. [14]

Procedural programming has both its advantages and disadvantages. The former include the following: all the code is in one file, therefore, the compiler does not need to go through multiple files. Secondly, it is much easier to keep everything in one place, since no referencing of items from other files is required. Also, if the code is neat, it will be very easy for a user to read everything. Contrastingly, one of the disadvantages of procedural programming is that there is no security since the data is exposed to the entire application. Moreover, if a modification needs to be made, the programmer must search through the file in order to find the correct place, also, if it is referenced in other places, the modification must be done there as well.

1.1.2 Object-Oriented Paradigm

As opposed to the former paradigm, Object-Oriented Programming consists of creating a set of classes and functions which give the program a structure, making it organized and easy to understand. OOP is a type of programming paradigm in which programmers define not only the data type of a data structure, but also the types of operations that can be applied to the data structure.

The Object-Oriented Paradigm is an evolvement of the Procedural Paradigm. It solves a number of issues that the latter had, including structural and security problems. One such security issue is the fact that in procedural programming, there is no security, as all variables are open for the entire program to edit.

This issue was recognized around 1970 by David Parnas. In order to solve the matter, Parnas thought of the idea to encapsulate each global variable in a module, along with a group of operations that will only have access to that variable. Other modules would have access to these variables; however it would be indirectly, by calling the specific operations. [14]

Another issue that is solved is the structural issue, as in the Object-Oriented paradigm, all the code is stored into separate classes and is not in the same class. This makes it easier for the developer to code the application and for maintenance in order to solve an error.

Advantages of Object Oriented Programming:

Allows objects to be created once and used repeatedly, therefore reducing the amount of code used.

Can break down projects into many files, thus making it much more organized when searching for something.

Much easier to maintain as the code is separated into multiple files.

Disadvantages of Object Oriented Programming

Each time a new object is created in a separate class, it adds more load to the compiler when compiling the application.

1.2 Software Quality Metrics

Software Quality Metrics are the processes that are used in order to validate the software processes used for the development of the program. Metrics can be used in order to improve the productivity and quality of the project.

The different categories of Software Metrics include Size Metrics; Complexity Metrics; Halstead's Product Metrics and Quality Metrics.

Size Metrics:

Lines of Code

Function Points

Complexity Metrics

Cyclomatic Complexity

Information Flow

Quality Metrics

Defect Metrics

Reliability Metrics

Maintainability Metrics

1.2.1 Size Metrics

This is one of the most widely used metrics as it attempts to quantify the software "size". The Lines of Code (LOC) metrics, for obvious reasons, cannot be measured until the program is complete; however, Function Points and System Bang have the advantage of being measurable during the development process.

1.2.1.1 Lines of Code

The Lines of Code (LOC) is a size metric frequently used for program size. It seems very easily and perfectly definable; however, there are numerous definitions for the LOC in a particular application. These differences involve the following:

Blank Lines and Comment Lines

Non-Executable Statements

Multiple Statements per Line

Multiple Lines per Statement

and how to count re-used lines of code

The most frequent definition of LOC is to count any line that is not blank or common, ignoring the number of statements per line.

The LOC metric is useful, as it can predict the quantity of program complexity, performance, and, the effort used in order to develop the program.

1.2.1.2 Functional Points

This software size can be determined earlier on during the development process. The approach used to calculate the total Function Points (FP) for the project, is based upon the following listed along with the weight that they have:

External User Inputs - 4

Inquiries - 4

Outputs - 5

Master Files - 10

Each contribution to the FP can be adjusted within a range of ± 35% for the specific project complexity.

1.2.2 Quality Metrics

Among the number of Quality Metrics that are in existence, there is portability, reliability, efficiency, maintainability and correctness. These characteristics however, may cross and conflict with each other, for example, increased portability could cause lower efficiency. A lack in correctness could result in a need for greater maintainability.

1.2.2.1 Defect Metrics

The final product after development has finished should be free from defects as much as possible. Since there is no standard method to calculate the amount of defects in a program, a number of alternative procedures have been suggested.

These suggestions depend on both the outcome and the final result of a phase from the development cycle, and the program. This is the list of alternatives that has been suggested:

The number of errors detected by inspections of code

The amount of changes in the design of the program

The total number of changes that the code required

The number of errors that were detected by tests of the program

As Mills (1988, 10) Suggests,

"The number of defects observed in a software product, provides, in itself, a metric of software quality."

1.2.2.2 Reliability Metrics

The rate at which a software metric fails, or, the probability of one failing, are both good for a programmer to know. The MTTF (Mean Time to Failure), or, the prediction of the probability of a failure, during a specific time interval, are both tried to be calculated by using this metric.

These metrics, for the most part, are mainly talked about in the context of creating a reliability model, of the behaviour, of the software process.

1.3 Halstead’s Complexity Metrics

As Halstead (1977) describes:

"Software Science being experimental involves measureable properties of algorithms. Such properties can either be measured directly or indirectly."

The need of Computer Science in general and Software Engineering particularly, began the investigation which led to the discovery of this branch of physical science.

1.3.1 List of Symbols

The following are symbols used by Halstead, M. in order to understand his formulae:

n1 - Unique Operator Count

n2 - Unique Operand Count

N1 - Total Number of Operators

N2 - Total Number of Operands

1.3.2 Program Length

The method that Halstead uses to calculate the program length, also calculates, indirectly, the program size.

Equation to calculate the Program Length:

N = N1 + N2

1.3.3 Program Volume

When an algorithm is translated from one programming language to another, or in this case, one paradigm to another the size changes. For such a change in size to be analysed, the size must be a measurable quantity.

1.4 McCabe Object-Oriented Software Metrics

The McCabe Object Oriented Software Metrics represent are split into 4 categories; Encapsulation, Polymorphism, Quality and Other metrics.

1.4.1 Encapsulation Metrics

Percent Public Data – It is the percentage of Public and Protected data within a class.

Access to Public Data – This is used to indicate the number of accesses to Public and Protected data within a class.

1.4.2 Polymorphism Metrics

Percent of Unoverloaded Calls – The number of non-overloaded calls in the system

Number of Roots (ROOTCNT) - ROOTCNT is the total number of class hierarchy roots within a program.

Fan-in (FANIN) - FANIN is the number of classes from which a class is derived.

1.4.3 Quality Metrics

Maximum v(G) (MAXV) - MAXV is the maximum cyclomatic complexity value for any single method within a class.

Maximum ev(G) (MAXEV) - MAXEV is the maximum essential complexity value for any single method within a class.

Hierarchy Quality(QUAL) - QUAL counts the number of classes within a system that are dependent upon their descendants.

1.4.4 Other Metrics

Depth (DEPTH) - DEPTH indicates at what level a class is located within its class hierarchy.

Lack of Cohesion of Methods (LOCM) - LOCM is a measure of how the methods of a class interact with the data in a class.

Number of Children (NOC) - NOC is the number of classes that are derived directly from a specified class.

Response For a Class (RFC) - RFC is a count of methods implemented within a class plus the number of methods accessible to an object of this class type due to inheritance.

Weighted Methods Per Class (WMC) - WMC is a count of methods implemented within a class.

1.5 Complexity

The measurement of Software Complexity is a specific area of software engineering, which is concerned with the measurement of factors that affect mainly the development, and the maintenance following it.

There are three specific psychological complexities that can influence software, have been identified. These are the system design complexity, the procedural complexity, and the problem complexity.

Procedural complexity is in conjunction with the logical structure of an application. This approach to the measurement of the complexity, takes an assumption of the length of the program, and of the amount of logical constructs.

The Problem complexity, simply put, takes the assumption that difficult and complex problems, are harder for a programmer to understand than simple ones. This type of complexity is generally ignored when analysis takes place, since it is impossible to control and different for every programmer.

System design complexity mainly addresses the mapping of a problem space, into a defined representation. Data and structural complexity are two types of complexities which are defined for the structures of systems.

Structural complexity addresses the concept of coupling, which is the measurement of the interdependence of the modules of the source code. Data complexity takes into account cohesion, which will measure the interdependence of each module in the application. It is mainly assumed, that if there is more cohesion in a module, it will be easier for a developer to understand it.

Every known programming paradigm has some form of complexity. The Object-Oriented paradigm has many acclaimed benefits, such as faster development, easier maintenance and increased scalability.

One of the main reasons for this is that the Object-Oriented paradigm takes on the code complexity, by accepting support of a hierarchical structure, both through procedural abstraction and data. The decomposition process of the OO paradigm, merely helps to control the complexity of the problem, it does not eliminate it.

Software complexity has been the interest of developers for quite some time. Software complexity has been identified as a large factor, in the cost of maintaining and developing the software.

1.5.1 Complexity Metrics

There are a number of metrics that can be used to measure the complexity of a program, most likely more than any other application characteristic. Like the Size Metrics, measurements of the complexity that can be calculated in the early stages of development of an application will be very useful in the management of the software process.

1.5.1.1 Cyclomatic Complexity

Cyclomatic Complexity represents the number of paths that a program can take to completion. In Cyclomatic Complexity, a program can have its control flow graph, G, drawn, wherein each node corresponds to a sequential code and each arc corresponds to a branch or decision point in the program.

With Cyclomatic Complexity, the number of the paths that the program must take can be calculated, and, using this number, it can be determined whether it is better than a similar program or not.

As McCabe (1976) introduces CC:

"Cyclomatic complexity measures the amount of decision logic in a single software module"

As an example, if a program in one language has a Cyclomatic Complexity of 25, and, in another language, it has a Cyclomatic Complexity of 21, then the second program would be more ideal to use.

1.5.1.2 Knots

The perception behind program knots is the drawing of, the program control flow graph, with a node representing each statement, or each block of sequential statements.

1.5.1.3 Information Flow

The Information Flow within the structure of a program can also be used as a metric for program complexity. As Henry and Kafura have proposed, their method is to count the number of information flows going in (flow-in) and going out (flow-out) each procedure. The complexity of the procedure is then defined as

C = [procedure – length]. [flow-in. flow-out]2

The programming effort, maintenance effort and debugging performance are all related to the complexity metrics. These metrics could also be used as indicators of the strength of security mechanisms needed by the application, in the context of security. In order for this to happen though, an amount of proof must be collected, in order to establish the relationship between the application complexity and the strength of the security mechanism needed.

1.6 Programming Languages

1.6.1 PHP

1.6.1.1 History of PHP

PHP is the creation of Rasmus Lerdorf. Developed in 1994, it is the successor of PHP/FI. Its first purpose was in order to track the number of visits towards his online resume. As time passed, added functionality was required, thus Rasmus had to rewrite PHP in order to produce a much larger and richer implementation.

The first public release of PHP was in 1995, which allowed developers to make use of it whichever way they desired. This release also encouraged its’ users to provide repairs and fixes towards to code in order to improve it.

1.6.1.2 PHP as a Multi-Paradigm Programming Language

PHP, in its creation in 1995, has evolved both as a language, and as a platform, with drivers spanning across all existing databases.

In the early years, PHP only supported the procedural paradigm, which proposed structured programming as the solution to every problem. Throughout this time, PHP was still used as a language for interactive documents, as web applications were non-existent.

Jumping to 2004, PHP 5 is released, and with it comes the improved support for the object-oriented paradigm. Though in PHP 4, the object engine had been created, but it was not created in the most usable manner, since it treated objects just like variables, passing clones of the objects, rather than the object itself.

Data Collection & Methodology

2. Introduction

Having established the basis of the theoretical outlook of this dissertation, it is now necessary to reveal the method that will be used to gather and support the evidence for the argument created in this dissertation.

The findings in the Literature Review, particularly the research consisting of Software Quality Metrics, proved to be useful in compiling the methodology, as it goes hand in hand, in solving the research question specified.

There are numerous approaches in which the evidence could have been collected, but in order to have the satisfying results, a set of parameters was established, including the programming languages and software metrics to be used, and what will be used to analyze them, including how it will be done.

Researching the various software quality metrics available has proven crucial in this dissertation. This is due to the fact that not all metrics were useful in solving the research question provided. The various programming languages available and the paradigms they support were also of interest to research. As specified in the Literature Review, PHP is one such language that supports multiple paradigms; however, there are other languages which support multiple paradigms.

The Size Metrics researched, particularly the "Lines of Code" and "Function Points", were implemented, since it was sure that there would be differences in both of these metrics between Object-Oriented and Procedural applications. These were useful more-so since the same application / website will be developed using both paradigms.

The Complexity Metrics studied provided the details necessary to see how the application had to be altered, in order to create it using the alternate paradigm. These details were provided by using Defect Metrics, as they will give a clear insight into how the design was altered, how many errors were found in the current algorithm, and what changes were necessary in order for the function to work properly.

Cyclomatic Complexity was thoroughly re-searched, since implementing gave an in-depth view of how the structure of the two paradigms varies. This software quality metric was used to identify the number of statements and loops, which was to prove whether the hypothesis is correct in stating that Object-Oriented programming is more efficient.

Halstead’s product metrics was also be incorporated into this study, to determine certain differences between the two applications, created in the different paradigms. These differences proved vital in determining which of the paradigms is greater, as these metrics included the difference in size of the applications and the number of operands and operators in each application.

In order to prove the hypothesis, that the Object-Oriented paradigm is superior to the Procedural paradigm, the same application, incorporating the same functions was created in both paradigms. This showed how the programming language would hand the same functions, and if they were to be implemented using the same logic, or have a new algorithm created to handle it.

The analysis of the applications that was created is the pinnacle of this dissertation. The applications researched in the Literature Review provided the necessary metrics in order to establish which paradigm is more efficient. Though metric_fu (used for Ruby) and PHPDepend (used for PHP), are both tailor made for their specific languages, there is not one application that will handle both.

In order to solve this issue, a separate application, utilising a GUI was created to calculate the metrics for both programming languages. The results obtained from this application, were for both languages, and show the difference between the procedural and object-oriented paradigm.

The reason that this dissertation is being done is to identify, whether programming using the Object-Oriented paradigm, proved more efficient, user-friendly, maintainable and scalable than the Procedural paradigm. There is also no detailed study of which of the two paradigms is better, only Forums and Blogs with discussions, therefore it will prove useful for those who wish to have a better insight into why the Object-Oriented paradigm is better (if so) than the Procedural paradigm.

2.1. Implementation

2.1.1 Introduction

Now that the foundation of the theoretical aspect of this thesis has been established, it is now necessary to visualize on how the evidence required proving the hypothesis will be collected.

In order to prove which of the Programming Paradigms is the better one, a number of applications and websites shall be created in both of them, then compared. Various programming languages shall also be used in order to assess comfort in coding in different languages.

For the creation of the applications and websites, a number of coding rules will apply, such as the notation used for the naming of variables, and how comments will be written, among others.

2.1.2 Applications

Two websites shall be created using PHP as a programming language. PHP has also been chosen since it is a multi-paradigm programming language. The websites will display information regarding the latest in technological advances, mainly PC’s, Laptops and Tablets.

For the Object-Oriented website, each item will have its’ own separate web-page, with the menu calling each separate one. Any media will also be placed into separate folders.

For the Procedural website, the text in the content section will change depending on the menu item that the user selects. All media will be placed into the root folder.

The design of the website will be simple yet attractive, with the sections clearly separated, but not wasting any space on the screen.

2.1.3 Assessing the Websites

Software Quality Metrics will not only be used to assess the two applications and two websites, however, there are other important factors that must be taken into consideration when developing a program.

Time Taken – More often than not, developing a program using the Object-Oriented pattern will take reasonably longer than the Procedural pattern, mainly since multiple classes must be created, then called. This will be an important factor for this dissertation in order to decide which paradigm is better.

Scalability – Many times, applications must be upgraded in order to handle more workloads; will this be easier using a Procedural Paradigm or an Object-Oriented Paradigm?

Maintainability - Should an issue occur, or an update for the information online is available, will this be easily applied or fixed?

Complexity - Which one of these two websites will be created faster? And which one with less hassle? This will be crucial in determining which Programming Paradigm is the better.

Research Required - How much research needs to be done in order to create the website.

Each one of these categories will be described in detail for each website, and given a number starting from 1 as easiest, to 10 as hardest, for the difficulty encountered for each one.

Time Taken

Scalability

Maintainability

Complexity

Research Required

Procedural

OOP

After all of the testing is complete, the best website will be decided on by the amount of points in each respective category. This will be done, since, for example, if a 10 is given to both Maintainability, and to Time Taken, this would mean that the website is would be perfect for maintenance after completion, but would take a long time to develop.

The Software Quality Metrics used for the websites would be the Program Size, and the Lines of Code. These would first be measured individually, then together, in order to see if there would be any difference when combined.

2.2 Development

2.2.1 Object-Oriented Website

2.3 Assessing the Software Metrics

The software which will be used in order to assess the Software Quality Metrics is PHP Depend, which can be used to give a thorough analysis of PHP source code.

2.3.1 PHP Depend

This application was developed by Manuel Pichler. The scope of the application is to analyze static PHP source code, and presents the user a report indicating the software metrics, among them, the CCN (Cyclomatic Complexity Number), the LOC (Lines of Code), and the NOF (Number of Functions).

PHP Depend is run from the Linux Operating System through the terminal. The report comes out in the form of a .xml file. It also generates two charts, one showing the interior dependencies

Figure .1 PHP Depend Analysis

http://pdepend.org/screenshots/full/command-line.png

Figure 1.2 PHP Depend Generated Graph

Findings

Discussion of Findings / Results

Conclusions & Recommendations

For future projects, testing the application on larger scale projects and if possible full scale systems, would give the most accurate results possible.

Bibliography

[1] Halstead, M. H. (1977). Elements of Software Science. New York: Elsevier.

[10] Pichler, M. (n.d.). PHP Depend. Retrieved March 2012, 20, from PHP Depend: www.pdepend.org

[11] Rajagopalan, S. (2006, June 10). Object Oriented Programming Paradigm. Retrieved February 4, 2012, from http://www.exforsys.com/tutorials/c-plus-plus/object-oriented-programming-paradigm.html: http://www.exforsys.com/tutorials/c-plus-plus/object-oriented-programming-paradigm.html

[12] Sironi, G. (2010, September 10). What paradigm should PHP applications embrace. Retrieved April 30, 2012, from DZone: http://css.dzone.com/polls/what-paradigm-should-php

[13] Suraski, Z. (2010). DevX. Retrieved April 30, 2012, from The Object-Oriented Evolution of PHP: http://www.devx.com/webdev/Article/10007/1954

[14] Watt, D. A. (1990). Programming Language Concepts and Paradigms. Hertfordshire: Prentice Hall International.

[2]. (2010, May 5). Software Quality Metrics. Retrieved January 31, 2012, from Toolbox: http://it.toolbox.com/wiki/index.php/Software_Quality_Metrics

[3] Allen, S. (n.d.). Object Oriented Programming Benefits. Retrieved February 15, 2012, from Dot Net Pearls: http://www.dotnetperls.com/oop

[4] Brownlee, J. (2011). Clever Algorithms: Nature-Inspired Programming Recipes. Northern Carolina: Lulu.

[5] Consulting, B. (n.d.). Burleson Counsilling. Retrieved February 15, 2012, from Advantages and Disadvantages of Object-Oriented Approach: http://www.dba-oracle.com/t_object_oriented_approach.htm

[6] DeMarco, T. (1982). Controlling Software Projects: Management, Measure & Estimation. New York: Yourdon Press: New York.

[7] Heinzl, R. (n.d.). Concepts For Scientific Computing. Retrieved February 5, 2012, from IUE Tuwien: http://www.haskell.org/haskellwiki/Functional_programming#What_is_functional_programming.3F

[8] Kafura, D. H. (1981). Software Quality Metrics Based on Interconnectivity. Journal of Systems and Software, 121-131.

[9] Mills, E. E. (1988, December). Software Metrics. Retrieved February 16, 2012, from SEI Curriculum Module SEI-CM-12-1.1: http://www.sei.cmu.edu/reports/88cm012.pdf