1Taxonomies, Paradigms, and the Untangling of Terminology
Untangling Terminology, Part 2—“Procedural”, “Object-Oriented”, or “Event-Driven”?
Download 210.5 Kb.
|
- Navigate this page:
- 1.3.1.1A brief summary of the procedural (or procedure-oriented) programming language paradigm
- 1.3.1.1.2explicit interaction with values in memory
- 1.3.1.1.2.2“Preservation of State”
- 1.3.1.1.2.3“Side effects”
- 1.3.2.1A brief summary of object-oriented features (Farrell, p. 356)
- 1.3.2.1.4Method Overloading
1.3Untangling Terminology, Part 2—“Procedural”, “Object-Oriented”, or “Event-Driven”?1.3.1“Procedural”On pp. 92 and 343, Farrell seems to define “procedural” to mean something akin to what I have called “Class 1 high-level program logic”. The problem with the term “procedural” is that it is widely used to distinguish a particular class or paradigm of programming languages, rather than a particular form of program logic. You can sample some of the range of usage for “procedural” and related terms under “Taxonomies of Programming Language Paradigms”, below. I have tried to gather together some of Farrell’s usages under “Taxonomies of Program Logic Styles”, below. It should be noted that languages in the procedural paradigm may include nonprocedural features, such as declarations, expressions, and functions. Similarly, many nonprocedural languages may have some features more typical of the procedural paradigm. There is also interest in mixed- or multiple-paradigm programming languages. 1.3.1.1A brief summary of the procedural (or procedure-oriented) programming language paradigm:1.3.1.1.1explicit flow of control:1.3.1.1.1.1The problem or its solution is expressed in terms of sequential steps.1.3.1.1.1.2Repetition may be expressed in terms of the iteration or looping of steps.1.3.1.1.2explicit interaction with values in memory:1.3.1.1.2.1In third generation procedural languages (COBOL, BASIC, C, etc.), this is accomplished by using1.3.1.1.2.1.1programmer-named variables to designate single values or aggregations of values (arrays, records, etc.) in memory, and 1.3.1.1.2.1.2assignment or input steps to update the values of variables. 1.3.1.1.2.2“Preservation of State”Values in memory are retained unchanged (“preservation of state”) until an update step is executed or the memory is released. When a variable (or memory location) is referred to, other than when receiving an update, its most recent value, or values, in the case of aggregates, are made available for further processing or output. (In a multitasking environment, the update might be performed by an independently executing module.) 1.3.1.1.2.2.1Modules might be allowed to preserve private state between invocations. 1.3.1.1.2.3“Side effects”Modules might not be restricted to returning values through the standard parameter and return value mechanisms, and might be allowed to update (global) memory values that will be available to other modules after the module exits. 1.3.1.2Nonprocedural programming language paradigms minimize or eliminate the above features.1.3.2“Object-Oriented”In the Tip on the bottom of p. 92, Farrell seems to distinguish between “procedural” (i.e., Class 1 high-level program logic) and “object-oriented” programs. She further defines “object-oriented programming” on pp. 356-7. In the latter case, she emphasizes the similarities between object-oriented and “modular procedural programming”. There is considerable, although not complete, agreement throughout the computer science discipline about the major characteristics that distinguish object-oriented programming and programming languages. However, there is a notable degree of variability in the ways various authors place object-orientation in programming and programming language taxonomies. This may be in part due to the various ways object features have been implemented. In some cases, object features have been added to an existing procedural language. Examples of this include Simula, the first object-oriented language (based on ALGOL), and C++ (based on C). In other cases, new languages have been created from the ground up based entirely on object concepts—Smalltalk, for example. Another example is Java, which is based entirely on object concepts, but adopts those parts of the C and C++ languages which can be made entirely safe and consistent with its object concepts. There are also efforts to bring object concepts to nonprocedural programming language paradigms. The power of object-oriented programming and programming languages has commonly been applied to help manage complex programming tasks, especially graphic user interfaces. However, it can just as well be applied to other processing modes (such as “batch”) and other forms of program logic (such as “Class 1”, what Farrell calls “procedural”). For the above reasons, I would strongly caution against the inference from Farrell’s statements that “object-oriented” programs form a separate class from “procedural” programs, either in her sense as a class of program logic or in the sense of a programming language paradigm. I would suggest that object-oriented programming be classified as a programming method or “methodology” that can be applied to a programming language paradigm, processing mode, or class of program logic. See below. 1.3.2.1A brief summary of object-oriented features (Farrell, p. 356):1.3.2.1.1Attributes and MethodsYou analyze the objects you are working with [What are their “attributes”?] and the tasks [“methods”] that need to be performed with, and on those objects. 1.3.2.1.2MessagesYou pass messages to objects, requesting the objects to take action [using their methods]. 1.3.2.1.3PolymorphismThe same message works differently (and appropriately) when applied to different [classes of] objects. [In some languages, the programmer will need to provide separate logic for each of the different object classes. Some languages may provide mechanisms, such as “templates”, that help generate the logic for multiple object classes.] 1.3.2.1.4Method OverloadingA module or procedure can work appropriately with different types of data it receives, without the need to write separate modules. [As with polymorphism, in some languages the programmer will need to provide separate logic for the various combinations of data types, or use features such as templates. Overloading may be available in non-object-oriented languages, such as C.] 1.3.2.1.5InheritanceObjects [or object classes] can share or inherit traits of [classes of] objects that have already been created, reducing the time it takes to create new [classes of] objects. [Attributes or messages/methods defined for a “child” class may “override” an identically named attribute or identical message/method defined for a “parent” class.] 1.3.2.1.6EncapsulationEncapsulation and information hiding are more complete [i.e., more powerful and flexible] than with the modules used in procedural [i.e., non-object-oriented] languages. [Encapsulation can be applied to both attributes (data) and methods (functions).] 1.3.3“Event-Driven”While Farrell gives pretty clear, standard, un-entangled definitions for “object-oriented” programs and programming in chapter 12, and of “event-driven” programs and programming in chapter 13, the Tip at the bottom of p. 92 is a rather different story. She states that “A distinguishing feature of many object-oriented programs is that the user determines the timing of events in the main loop by using an input device such as a mouse”; but that distinguishing feature is, in fact, a definition of event-driven programs (see below). So, she is saying that many object-oriented programs are also event-driven programs, which is technically correct. Just don’t take that distinguishing feature of event-driven programs as a definition of object-oriented programs. See also Jo-Mae B. Maris at Northern Arizona University (http://www.cba.nau.edu/facstaff/maris-j/CIS220/220Notes/L8Program.Ppt#17). Here follows a recap of some source materials. [My comments and clarifications (hopefully) are enclosed in square brackets.]
Download 210.5 Kb. Share with your friends:
|