15 September 2006

Object-Oriented Programming

Objected-oriented programming (OOP) is an enormous topic, in part because it embraces many collateral topics, and because it is a nexus among all those topics. Object-oriented programming incorporates objects, which are basic program "building-blocks." In conventional programming, the program consists of a single, very large, number of instructions to the computer. But in OOP, the program is a population of objects with discreet methods and communication nodes. Each object acquires data

A class of objects is united by basic standardized attributes or functions. Each system of OOP requires a system of classifications for objects, rather like biological taxonomy. The structure of classes will of course include subclasses for each class (and so on); a subclass is said to inherit the attributes of its class, and add others that differentiate it from other subclasses of the same class.

An example might be the database of a university, which has instructors, students, support staff, departments, and courses. There are three classes of objects: persons, organizations, and courses. The class of persons has subclasses of staff, students, and instructors.


The subclass of student inherits various attributes, such as possessing an address and phone number, but differs from the instructor in that the instructor teaches classes, and the student is enrolled in them. We might conceivably have all the violet boxes (classes) united under a class school, with attributes all of the classes inherit--e.g., all are members of an organization. I should mention that the semantics of computer programming is very different from that of spoken languages, and only occasionally coincides with that of math. So, for example, my example of a class system has unfortunately assumed human language semantics. Arguably a department might be defined as a type of person that inherits all person characteristics, but is distinguished from an instructor solely insofar as the instructor can only "have" one course at a time.

An obvious example of programming semantics violating either math or human language semantics is the command, x = x + 1; it merely tells the computer to replace the value x with (x + 1) in the register. In OOP, it is not unusual for incompatible geometric objects to be treated as related, e.g., the class circle belongs to the class point, with the additional characteristic that it has a radius. Presumably the subclass rectangle belongs to the class point as well, but has height and length.

A method is one of the things that the object does. As an object, we expect that the way in which an object executes its mission is encapsulated, i.e., hidden from the "view" of other computer programs. This means that computer programs are not expected to hack the behavior of objects, for altering their methods. A crucial component of methods is how they are bound to their variable. If the variable is defined in the code as (say) an integer, or perhaps a floating-point value, then it is statically bound to the object. If variables are declared in way that allow them to vary, they are dynamically bound.[*]

When objects communicate with each other, while they are encapsulated, there are also different levels of access; members of the same class will have more access than those that are not, unless they are friends--i.e., objects assigned special access by the programmer. Access allows the use of pointers among objects, or links to specific variables (specifically, pointers point to a section of memory space where a variable is stored; objects with pointers to a particular variable can monitor that memory space and "know" what to do with the contents.

Another aspect of objects is polymorphism, which is the ability of objects to take on the characteristics and responses of other objects. Typically, short introductions like this one use highly improbable analogies, such as referring to objects as dogs or cats; so I am especially grateful to Prof. Müller for giving us a break and actually explaining the concept seriously. It turns out there are two conceptions of polymorphism in OOP. One refers to the ability of objects to use multiple definitions of variables, so that a function can check for multiple conditions for a value being true in an single step (e.g., a number being within a desired range of another; which may require a test for it being in range, and being the number desired. This is actually something conventional programming languages can do, of course, but usually it is a bit more complicated.

The other form of polymorphism is the inheritance of pointers and methods. By this, we mean all the objects of a subclasses will inherit certain standard methods from their superclass, although the way these objects respond to the same stimulus will vary depending on the object. A subclass of objects will respond to the same pointers as those of the class above it (the base class). The purpose of this is to allow a formal array of permissions to variables created and stored by objects.

Benefits & Criticisms

It must be noted that while object-oriented programming is extremely common, it is not without controversy. What really pushed OOP into the mainst ream was the use of graphical user interfaces (GUI's); modern applications running in a GUI are typically miniature operating systems, with each of those drop down menu options or icons standing for a program. Click on the menu, and a new program is launched. Developers appreciate the ability to drag and drop many of these programs into the visual space of the integrated development environment (IDE). Virtually all tuturials or guides on the subject of OOP refer to the benefit of code reusability.

Another advantage, evidently, is that OOP semantics heavily favor multithreading computing. OOP concepts are usually explained by analogy with zoology [*]: the typical class is dog; dogs are a subclass of animals, and collies are a subclass of dogs. Instances of the class dog have a method known as barking, and collies inherit this class from dogs. Another tutorial used the scholastic example I have used above [*], but did so literally; I tried to de-abstract this using various articles on C++ linked below, and no doubt there are serious flaws in my exposition. However, it seems fairly clear that the most compelling advantage to OOP is that it provides a ready-made formal system for running program processes as a group of separate threads. One of the more economical ways that threads can pass messages to each other is by saving them to a common memory sector, something that requires a carefully designed (or standardized) syntax.

Criticisms of OOP are that it's a needlessly exotic, arbitrary, and costly constraint on programming procedure. Applications written in OOP languages are too large for what they do; OOP requires requires programmers to effectively adopt a novel syntax that is much too remote from ordinary programming, yet the method provides benefits that are inconsequential. The experience with Unix and GNU suggests that code reusability is not a real problem; programmers have managed to create immensely complex programs using bits and pieces of code from all over. Sealing objects off so that they cannot be hacked by other objects is regarded by some programmers as bizarre, and certainly unnecessary. Some have gone so far as to claim that OOP is doomed to go the way of other fads. OOP implementation is far too difficult and has failed to increase productivity.

In a way, a far test is impossible because (on the side of the skeptics) there's no way of knowing what other, more apt, methods of coding huge applications might have been made to work better if the energy had been spent on them instead; and (on the side of the defenders), I'm skeptical of the argument that this was a burn-the-ships fad. Clearly, there had been a problem developing robust code for ever-larger applications, and the approach broadly embraced OOP. This was across languages and included the open-source movement as well as a lot of firms (C++ was developed at Bell Labs in '85; C# is from Microsoft; Common Lisp was an international convention developed and supported by ANSI to unify many variants; ANSI also developed Fortran 2003; PHP 5 is actively developed by Zend Technologies in Israel; Smalltalk was developed by Xerox PARC, and inspired the development of Stepstone/Nextstep's Objective-C; Java, as everyone knows, was developed at Sun Microsystems.).

Political fads are the stuff of game theory, because they're about acting in groups. So history is full of dire political fads. But it's hard to come up with an example of a totally invalid scientific or engineering fad that had many different points of origin.

See also Unified Modeling Language (UML)


ADDITIONAL READING & SOURCES: Wikipedia entries for Object-oriented programming: OOP languages, Unified Modeling Language (UML), Executable UML; Aspect-oriented programming;

Peter Müller, Introduction to Object-Oriented Programming Using C++ ; "IBM Smalltalk Tutorial - Table of Contents"; Richard Mansfield "OOP Is Much Better in Theory Than in Practice"(2005); B. Jacobs, "Object Oriented Programming Oversold!";

BOOKS: An Introduction to Database Systems-7th Edition, C.J. Date, Addison-Wesley (2000), Chapter 21; Harold Abelson & Gerald Jay Sussman, Structure and Interpretation of Computer Programs, MIT Press (1996; complete text online); Chapter 3;

Labels:

0 Comments:

Post a Comment

<< Home