Dar's Blog

A Look at Object Oriented Programming

Details

Created on Tuesday, 29 May 2012 19:35

Last Updated on Tuesday, 29 May 2012 19:52

Written by Administrator

Hits: 529

Abstract

There is a lot of debate in the world of programming about the merits of Object Oriented Programming (OOP). In order to understand the debate, an in-depth look at OOP is required. This paper will take time to look at the key components of OOP, such as classes and objects, and compare them to some of the features that OOP is known for. These features include Abstraction, Encapsulation, Inheritance, and others. Each of these components has a specific part to play in planning and creating a program, and helps make Object Oriented Programming a flexible and useful model for programming.
 
Benefits of Object Oriented Programming
In 1993, Uday S Murthy and Casper E. Wiggins, Jr. published a paper about Object-Oriented Modeling for the Journal of Information Systems. In it, they discuss various different then-common programming paradigms and how they related to data models. (Murthy & Wiggins, Jr, 1993)
Murthy and Wiggins assert that, “the notion of an object emerged from various hardware and software fields within computer science at least twenty years ago. Since that time object-oriented concepts have evolved and have been influenced by many factors such as advances and developments in computer hardware, programming languages, programming methodology, database models, artificial intelligence, philosophy, and cognitive science.” (Murthy & Wiggins, Jr, 1993, p. 101) So, the idea behind objects actually coalesced from several different (and often wildly dissimilar) areas of life.
The Object-Oriented method was pushed ahead further by the development of Object-oriented programming languages. Some of these early languages included Simula, Smalltalk, C++ and Objective C. (Murthy & Wiggins, Jr, 1993, p. 101)These various languages came to encompass the very definition of Object-Oriented, “analysis, design, programming, or database management approaches that exhibit the basic characteristics of the object data model.” (Murthy & Wiggins, Jr, 1993, p. 101)
When it comes to what makes up the ‘basic’ Object-Oriented model, “the [Object-Oriented] foundation elements are generally agreed to include the concepts of object, class hierarchy, and inheritance.” (Murthy & Wiggins, Jr, 1993, p. 102) They go on to contend that there are four pieces that make the Object Oriented Model a successful one:
“An object-oriented analysis and design methodology should address the following four critical components: (1) guidelines for object-oriented analysis (modeling of the problem domain), (2) guidelines for object-oriented design (modeling of the solution domain), (3) a representation scheme for the static and dynamic aspects of the domain and the constraints pertinent to each of these two aspects, and (4) a mechanism and representation scheme for complexity management. In the information systems literature, a distinction is often made between systems analysis techniques, which refer to the problem domain representation, and systems design techniques, which refer to the solution domain representation.” (Murthy & Wiggins, Jr, 1993)
What is an Object? According to Microsoft’s MSDN website, an Object is basically an area of memory that has been carved out and shaped according to a blueprint. (Microsoft Inc.)In the case of C#, that blueprint is a class. These objects are able to be created over and over from the same class. Each of these types of objects is known as “instances”, and can be stored in named variables for use. (Microsoft Inc.)
This ability to re-use code, specifically objects, has allowed the Object-Oriented model to excel. One area in specific has come in with data types. In using the Object-Oriented mode, a program can have, “both complex data types and user-defined data types.” (Murthy & Wiggins, Jr, 1993, p. 103) This allows for a lot of flexibility when it comes to writing programs. The objects can, within a class, be passed different parameters and saved in their own variables, which saves a lot of time when programming.
These objects are often found in classes. In C#, a class is a framework and design document from which a number of different objects are able to be created. Every class has a constructor that allows it to be used. The constructor in a class allows for custom arguments or parameters to be integrated into the code. This is what gives each object its flexibility. Attributes can be modified dynamically, which allows classes to be re-used.
This leads to Inheritance. Microsoft’s MSDN website states that Inheritance is one of the three pillars of Object-Oriented programming. (Microsoft Inc.) Inheritance works in a number of ways, but primarily within classes it allows all sub-classes to have the properties that were defined within the base class.
This is useful when writing multi-layered programs. Instead of re-writing code over and over again, the object model and inheritance allows for simplicity. Writing the code that all the classes will need in the main class; then all sub-classes of that class will have those objects available to them as well. These relationships between classes and class-objects are called composition, which is used to describe shared information between objects. The opposite of composition is aggregation, which allows for pulling a single value out of a group of values. These are extremely useful when developing applications that get lots of information from various sources and then return parts of that information. (For example, returning the first number out of a credit card.) (Microsoft Inc.)
Part of writing these multi-tiered classes and subclasses is Abstraction. Abstraction in classes is where a single base class is never planned for use as an object. These classes will always have base classes because they are incomplete. (Deitel & Deitel, 2011) The sub-classes are instead instantiated into objects.
Author’s A. H. Eden, Y. Hirshfeld, and R. Kazman indicate that Abstraction can be one of the most important parts of programming, because “At the lowest level of abstraction are concrete statements that are concerned with specific implementation details. An Implementation statement is not only ‘local’ but also ‘extensional’; it directly correlates to a specific part of a specific program.” (Eden, Hirshfeld, & Kazman, 2006, p. 163)
Several of these objects that get passed along are called Methods. Methods are bits of re-usable code that does one thing very well. A properly-structured method will not do more than one thing, and the code should be readable. This comes with the method’s name as well, because a descriptive and useful method name will keep code looking neat and organized. (May, 2012)
Properties within the classes can also be declared as abstract. These are overridden in derived sub-classes. This is important if there are special object-types that are needed for each sub-class – another example of the Object-Oriented method making it easier to re-use the same code. (Deitel & Deitel, 2011)
The main idea behind all of these being put together is called Encapsulation. Encapsulation is where the objects, attributes, and operations are tightly wrapped together. This allows the code to execute quickly and separately from other sections of the code.
This is used primarily for interfacing with other objects. Presenting the object singularly when being used (in the case of C#, something like Object.Class.Method(Parameters)) allows for readability and usability.  Structurally, it is easy to see where each part of the code comes from, and that allows for rapid debugging or changing of code if a problem should arise.
All of these require Access Modifiers, which determine what code can interact with methods, attributes, classes, and so-on. For example, a public modifier allows anything to interact with the code in question. That doesn’t allow it free range to modify whatever is in it, but it does allow it to set and get parameters as the code allows. Private, on the other hand, allows modification and interaction only within the scope of the containing object.
One of the biggest ideas to understand about the Object Model is that there are objects within objects. This allows for high-level object modification, as well as internal and low level manipulation. Re-usability is a strong-focus from this methodology.
Anders Hejlsberg did an interview with Newsweek in August of 2001. In it, he describes the ideology that went into designing C#. There were a lot of complaints from C++ users about how the language offered too much complexity. When designing the C# language, they decided to drop some of that complexity and let the language itself take care of the backend. (Eweek, 2001)
While still adhering to the Object Model, this idea is actually used in the Functional Programming Model. F#, a language also developed by Microsoft, works mostly on simple syntax and powerful results. Part of the functional method of programming has made it into C# in the form of LINQ. Using simple syntax, it is able to automate a lot of the work in the background to bring out powerful results. (Deitel & Deitel, 2011) This works much the same way as SQL does – a simple set of commands and the database backend does a lot of the work for the coder.
Anders went on to state that some of the complexity found in C++ was required. His estimation was that 2% of programs require the flexibility offered in languages like C# and Java. (Eweek, 2001) He also stated that C# borrowed heavily of the Syntax of Java, and that they both borrowed heavily of C++. He also gave some reasons to use C# as a primary development platform, in turn putting another reason to use the Object-Oriented Method. Those reasons included, “What platform are you programming? If you’re programming for the .Net platform and you are going to use ASP [ActiveServer Pages] .Net, well, then, I would argue that you should program in C# We have also submitted all of C# and a large subset of the .Net Framework to [standards body] ECMA. Ultimately, I am sure this will lead to implementations on other platforms. Java, the language syntax, is not a problem at all to put on our platform. But all of the class libraries that Sun has implemented are a different story.” (Eweek, 2001)
One of the detriments of the C++ language is its lack of readability. Compare the two following lines of code:
C#:
System.WriteLine(“Hello World!”);
C++:
cout << “Hello World!” << endl;
The syntax for the hello world app in C++ is slightly shorter, but the readability is much harder. It is imperative that a coder understand the language in full; this can require a lot of comments in the code for other coders to follow. C# is a self-documenting language that, when used properly, allows for maximum readability without excessive notes.
The problem is that C# is unable to naturally do low-level memory management. It doesn’t supply options for assigning or modifying pointers. That makes C# a language that is not well designed for advanced game design. There have been entire books written about C++ game design, (Beginning C++ Through Game Programming by Michael Dawson, for example) that teach how to modify pointers for speed when developing games. (Dawson, 2007)
C++ is another language that uses the Object-Oriented Model. In fact, it was one of the original programming languages to adopt it when the Object Oriented Model started moving forward heavily. Its two largest features over C# is that, A.) it can modify memory dynamically and directly, and B.) it can be easily used for cross-platform development because it doesn’t rely on the .NET Framework.
In this way, the C# language functions more like a Functional Programming language rather than an Object Oriented Language.
Functional Programming’s biggest area of improvement over the Object Oriented model is that it uses simple syntax. This allows for programs to be developed quickly. Microsoft developed another technology that works off of databases called “Lightswitch” that allows for application development with little or no code being written. The compiler creates most of the code for you and then simple syntax allows for further development of enterprise level applications. (Microsoft Inc.)
When it comes to program design, each of these has their own place in it. For example, when working with a database, the functional programming method is easier (and possibly a lot faster) for returning specific portions of the data you need, whereas programming a game might require something more complex. (Dawson, 2007)
Programming languages like LISP were designed with a very specific type of programming in mind, like Artificial Intelligence applications. This type of programming requires very certain programming practices, something that would take several months, if not years to learn. When programming general purpose applications, there are several design ideas that go into place.
There is a certain algorithm called the Monte Carlo that pushed algorithm programming out. This type of design requires forethought to the type of math that will be used. Each part of the algorithm is then translated piece by piece into the application as code that handles that part of the algorithm. Object Oriented programming helps because each part of the algorithm can become an object that, when used in order, can find an answer.
Programming for a game, however, requires a different kind of thinking, called “Logical Thinking”. Instead of trying to find an answer, it is instead required that a programmer determine what course of events the user will take, and how certain interactions with various parts of the program could change that. It’s a very interesting exercise in programming.
Coupling code together, then, is how tightly interwoven individual objects are within the code. Decoupling the code involves making the code stand alone, so that it is less inter-dependent. This can be good for huge projects where fault tolerance is required. (Miller, 2008) He goes on to explain that there are four main reasons that a programmer should focus on decoupling code:
“To summarize, the goals behind achieving loose coupling between classes and modules are to:
1.     Make the code easier to read.
2.    Make our classes easier to consume by other developers by hiding the ugly inner workings of our classes behind well-designed APIs.
3.    Isolate potential changes to a small area of code.
4.    Reuse classes in completely new contexts.” (Miller, 2008)
 This can, however, require additional code to be re-written because the program is not fully written. With coupling comes cohesion, which pulls together all aspects of the program. This is a big part of the Object-Oriented model. Designing all parts of the program together to work in perfect harmony increases cohesion, which allows programs to work faster and more accurately. (Miller, 2008)
Miller goes on to explain that, when using objects, it is best to be in full control of them. Basically, when using an object, the programmer should have full knowledge of what is going to happen. This is called the “Tell, don’t Ask” design, and is described as, “[A] design principle urges you to tell objects what to do. What you don't want to do is ask an object about its internal state, make some decisions about that state, then tell that object what to do. Following the Tell, Don't Ask style of object interaction is a good way to ensure that responsibilities are put in the right places.” (Miller, 2008)
When it comes to usability, however, there are a number of these features that the programming world doesn’t necessarily take every part to heart. Every part of Object-Oriented programming has come under attack from various different sections. Richard Mansfield, Author for DevX, states that Object Oriented Programming offers good benefits, “in theory”. (Mansfield, 2005)
In his article entitled OOP is Much Better in Theory Than in Practice, Mansfield likens the OOP method to going through airport security, in that, “It's a clerical system with some built-in security features. In my view, confusing OOP with programming is a mistake. OOP is to writing a program what going through airport security is to flying.” (Mansfield, 2005)
He brings up an interesting point, where “To keep your code bug-free, encapsulation hides procedures (and sometimes even data) from other programmers and doesn't allow them to edit it. Inheritance then asks these same programmers to inherit, modify, and reuse this code that they cannot see—they see what goes in and what comes out, but they must remain ignorant of what’s going on inside.” (Mansfield) For some programmers, this could be a daunting issue, like not understanding how the Log function on a calculator works.
He asks a question about how to program classes, whether the coder should use large abstraction-based classes, or smaller, compact code. (Mansfield, 2005) The idea that the entire method of Object Oriented Programming is to provide the right tool for the right job while also being a large toolbox does not seem to register as an option; it is all one way, or the other.
Mansfield takes the idea that Object-Oriented programming was developed for the specific purpose of “modeling such natural phenomena as weather patterns.” (Mansfield, 2005) His exposition brings about some very interesting complaints about coding – such as the idea that, “ten lines of code are now needed where one used to suffice.” (Mansfield, 2005) His statement is specifically relating to the usability of C-like languages, compared to languages such as basic.
As a supplement to his argument, authors Timothy Colburn and Gary Shute state, “Computer science, insofar as it is concerned with software, is distinguished from the empirical sciences in that none of its models are physically concrete—they are realized in software, and in this nonphysical sense computer science models are abstractions.” (Colburn & Shute, 2007, p. 170)
The article, however, ignores a number of the benefits of Object Oriented Programming, wherein even a moderately sized program that does calculations might be better if code could be re-used. The arguments that are usually lobbied against Object Oriented Programming often ignore its benefits as they try to deride the ideas and principles that might be a bit bloated.
A contrasting opinion about Object Oriented Programming is found from author Aden Evens, who states that Object Oriented Programming was originally developed in the early 1960’s. (Evens, 2006, p. 96) One of the arguments for Object Oriented Programming is called Scope. Evens discussed the importance of Scope by saying, “Scoping (and procedural programming) further encapsulate what is already encapsulated, gathering lines of code into modules, each of which operates independently and is referred to from without by its unique name.” (Evens, 2006, p. 92)
While Mansfield professed that Object Oriented Programming added too much fluff to the program itself, (Mansfield, 2005) Evens states that it’s use will eventually become inevitable. Evens stated that, “Procedural code – dividing the program code into distinct functional modules – does not organize these modules into overarching categories, nor does it organize the most general data that the program must operate on. Local variables, those scoped within a particular procedure, ‘‘belong’’ to that procedure, but plenty of data are global, accessible from within every procedure. These ‘‘unowned’’ data disrupt the inside/outside distinction, floating in the indexed space of random access memory.” (Evens, 2006, p. 92)
Evens contends that OOP is a very innovative language, that groups together “a number of different procedures along with a set of data that those procedures operate on, the whole group of procedures and data being called an object.” (Evens, 2006, p. 92) This allows the programmer to separate their code into operative entities and elements that can play pivotal roles in the design and function of a program. (Evens, 2006, p. 92)
Even Steve Jobs understood the power of Object Oriented programming. Walter Isaacson, the author of the Official Steve Jobs biography, went into detail describing when Steve Jobs was working on promoting the NeXT operating system; he touted how the operating system was fully Object Oriented. (Isaacson, 2011) Isaacson detailed that, during an interview with Bill Gates for the Biography that he recognized the power behind the Object Oriented Model, even though he thought the NeXT operating system wasn’t anything particularly new. (Isaacson, 2011)
It is understandable that there are aspects of Object Oriented programming that are not well liked. Areas such as methods and classes required for certain aspects of the GUI programming model. These are inherent in every C-based language, and it does provide some unwieldy programming at times. However, these key issues do not move to push the aspect of usability that the features bring together. A better method of programming might some-day become apparent, but for right now the programming paradigm offered in Object-Oriented programming makes it a key influence in the general realm of programming.
When it comes down to the basics of it, programming has its paradigms that bend from developer to developer. However, when it comes to building applications that are flexible, operate well, and are easy to maintain, the Object Oriented Method provides several key benefits that will allow it to maintain its current position as the status quo for programming and development. Functional and Procedural programming have their place, and Languages like C# have implemented these aspects where necessary (LINQ, as a primary example) it is important to remember that programming is rarely a single-person endeavor, and the features that are offered by the Object Oriented Method of Programming provide the necessary features and flexibility to make programming multi-level functional programs easy and usable. Languages like C#, Java, and C++ were designed around these models because companies like Microsoft and Sun have devoted years into developing tools that allow programmers to create intuitive, easy to integrate programs for others.
 
Bibliography
Colburn, T., & Shute, G. (2007). Abstraction in Computer Science. Minds and Mathematics, 169-184.
Dawson, M. (2007). Beginning C++ Through Game Programming, Second Edition. Boston: Thomson Course Technology.
Deitel, P., & Deitel, H. (2011). Visual C# 2010 - How To Program, Fourth Edition. Upper Saddle River: Pearson Edition, Inc.
Eden, A. H., Hirshfeld, Y., & Kazman, R. (2006). Abstraction classes in software design. The Institution of Engineering and Technology, 163-182.
Evens, A. (2006). Object-Oriented Ontology, or Programming's Creative Fold. ANGELAKI Journal of Theoretical Humanities, 89-97.
Eweek. (2001, August 20). Microsoft sharpens vision around C#. Eweek, p. 29.
Isaacson, W. (2011). Steve Jobs. New York: Simon & Schuster.
Mansfield, R. (2005, January 15). OOP Is Much Better in Theory Than in Practice. Retrieved May 3, 2012, from DevX: http://www.devx.com/DevX/Article/26776
May, S. (2012, March). In-Class Lecture. Springfield, Missouri, United States of America.
Microsoft Inc. (n.d.). MSDN. Retrieved May 3, 2012, from Microsoft Website: http://msdn.microsoft.com/en-us/
Miller, J. (2008, October). Patterns in Practice: Cohesion And Coupling. Retrieved May 3, 2012, from MSDN Magazine : http://msdn.microsoft.com/en-us/magazine/cc947917.aspx
Murthy, U. S., & Wiggins, Jr, C. E. (1993). Object-Oriented Modeling Approaches for Designing Accounting Information Systems. Journal of Information Systems, 97-111.