Using Object Oriented Programming

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, two websites, and two applications have been created. The first website and application were both created using the Procedural Method, and the second ones using the Object-Oriented Method.

During development and after it, Software Quality Metrics were used in order to determine a number of characteristics about each application, among them, the size, performance, and complexity of each one.

Introduction

Throughout my course over the last five years, I have always sought into making the most efficient applications possible using my skills. However, not all applications turned out as efficiently as I'd hoped they would. After assuring myself that the code was at its' most efficient level, I turned to the style that I was using in order to program.

Was the style I was using causing these applications not be as efficient?

Programming, throughout the years, has evolved continuously, and along with it, the style programmer’s use to program. This style has seen it change from an un-structured, Procedural way, to a structured, Object-Oriented format.

This led me to begin researching my question, on whether, given a certain type of program (large or small) to develop, would it be better to use the Procedural paradigm, or the Object-Oriented paradigm?

The context of my research would focus around the Procedural, and Object-Oriented programming approaches, and, Software Quality Metrics, which would 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 was evolved from the Procedural Paradigm.

However, these are not the only two paradigms that exist. There are other paradigms in use, being the Functional Paradigm, and, the Logic Paradigm. All of these paradigms were built up over a period of 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

This programming 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 built for the procedural paradigm include Pascal and PHP. Procedural Programming is also one of the first items thought to new programmers, in order to give them a solid grasp of programming and prepare them for future challenges.

The Procedural Paradigm has a very long history, since programming language designers, from times as early as the 1950’s, saw that assignment commands and variables, created a simple, but highly useful abstraction, from the memory fetch and update of machine instruction sets.

Advantages of Procedural Programming:

All the code is in one file, therefore, the compiler only has to go through one file, and not multiple files.

It is much easier to keep everything in one place, since you will not have issues referencing items from other files.

If kept neatly, it will be very easy for a user to read everything.

Disadvantages of Procedural Programming

If a modification must be made, the programming 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.

There is no security since the data is exposed to the entire application.

1.1.2 Object-Oriented Paradigm

Object-Oriented Programming consists of creating a set of classes and functions in order to 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.

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

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

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 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.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

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

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

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

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

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

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

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

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

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

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

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

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

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

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