1Taxonomies, Paradigms, and the Untangling of Terminology
Tom Ellman on Modes of Interacting with Input Objects (http://www.cs.vassar.edu/~ellman/old-courses/235-spring-2000/cs235-lecture17.pdf)
Download 210.5 Kb.
|
- Navigate this page:
- 3.4Art Gittleman ( Computing with Java™: Programs, Objects, Graphics: Alternate Second Edition , 2002, “1.4 Program-Driven vs. Event-Driven Applications”, pp. 15 ff.)
- 3.4.1The Character Mode [Batch Processing Mode/Program-Driven]
- 3.4.1.1Execute code in a step-by-step fashion like a recipe.
- 3.4.2.1Wait for the user to generate an event.
- 3.5.1Procedural Programs
- 3.5.2Event-based = Event-Driven Programs (Ch. 4, p. 92; Ch. 13, pp. 371ff)
3.2Tom Ellman on Modes of Interacting with Input Objects (http://www.cs.vassar.edu/~ellman/old-courses/235-spring-2000/cs235-lecture17.pdf)3.3Julia Case Bradley & Anita C. Millspaugh (Programming in Visual Basic 6.0, 1999, Ch. 1, “Programming Languages—Procedural, Object Oriented, and Event Driven”, pp. 3ff)3.3.1[Event Driven]The newer programming languages, such as C++ and Visual BASIC, us a different approach [from the “procedural” languages]: object-oriented programming (OOP) and event-driven programming. Microsoft refers to Visual BASIC as an event-driven programming language, which has many (but not all) elements of an object-oriented language such as Java. In the event driven-model, programs are no longer procedural; they do not follow a sequential logic. You, as the programmer, do not take control and determine the sequence of execution. Instead, the user can press keys and click on various buttons and boxes in a window. Each user action can cause an event to occur, which triggers a BASIC procedure that you have written. For example, the user clicks on a command button labeled Calculate. The clicking causes the button’s Click event to occur, and the program automatically jumps to a procedure you have written to do the calculation. 3.4Art Gittleman (Computing with Java™: Programs, Objects, Graphics: Alternate Second Edition, 2002, “1.4 Program-Driven vs. Event-Driven Applications”, pp. 15 ff.)Older programming languages support the program-driven style of programming in which our program executes from beginning to end following the steps of our code much like a cook follows a recipe. Java permits program-driven code, and further supports event-driven programming in which our program, like the firemen in the station, wait for an event to spur them into action. [Note that his definition of program-driven seems very similar to what I would call Class 1 high level program logic. Below you will see he ties this to batch processing mode. But as I try to show above, this is not a strictly one-to-one relationship.] 3.4.1The Character Mode [Batch Processing Mode/Program-Driven]… During these [early] years, computers executed programs in batch mode. The computer operator put together a batch of programs, using the card reader to feed then to the computer that executed the programs one after another, printing a listing of each program and the results. When the operating system started a program, that program had control of the processor until it finished executing. We call such execution program-driven because the program [rather, computer?] continues executing the program, one statement after the other until the program ends or a fatal error occurs. Executing such a program is like preparing a dish from a recipe. The cook is in charge, executing the steps of the recipe until the dish is complete. … Program-driven applications are still a very important part of computing. Preparing the payroll does not require user intervention. The payroll program takes input regarding hours worked and rate of pay and prepares the paychecks and other payroll records. As another example, the Java compiler takes the source program as its input and produces the byte code for the JVM [Java Virtual Machine] with no need for a graphical user interface, operating in character mode in which input and output consists of characters. The Big Picture: The program-driven approach suits applications such as compilers that require no user interaction. … 3.4.1.1Execute code in a step-by-step fashion like a recipe.3.4.1.2Transform input into output, without user intervention.3.4.1.3Typically use character mode.3.4.2The Graphical User Interface [and Interactive/Event-Driven]With monitors and operating systems capable of displaying graphics, we can develop programs that interact with the user via a graphical user interface (GUI). The operating system responds to the user’s input, conveying it to the program that passively waits for user input to request it to provide some service. We represent these user requests as events. An event-driven program includes code to respond to messages informing it about events involving its windows, such as button presses or data entry. The Big Picture: … Event-driven programs suit user interfaces whose components respond to user interactions such as pressing a button or making a selection. With the advent of more powerful computers with graphics capabilities, event-driven applications have taken a more important place in computing. 3.4.2.1Wait for the user to generate an event.3.4.2.2Include code to respond to that event.3.4.2.3Respond to user actions.3.4.2.4Typically have a graphical user interface.3.5Joyce Farrell Taxonomy (Programming Logic and Design, 2nd ed., 2002, Ch. 4, p. 92ff; Ch. 12, p. 343ff)3.5.1Procedural ProgramsYou can write a program that reads records from an input file and produces a printed report as a procedural program—that is, a program in which one procedure follows another from beginning until the end. You write the entire set of instructions for a procedural program, and when the program executes, each instruction takes place one at a time following your program’s logic. The overall or mainline logic of almost every procedural computer program can follow a general structure that consists of three distinct parts:
You can write any procedural program as one long series of program language statements, but most programmers prefer to break their programs into at least three parts. The main program can call the three major modules [that embody the three distinct parts, above]. Throughout most of computer programming history, which now totals about 50 years, the majority of programs were written procedurally. A procedural program consists of a series of steps or procedures that take place one after the other. The programmer determines the exact conditions under which a procedure takes place, how often it takes place, and when the program stops. The logic for every program you have developed so far using this book has been procedural. Tip: You first learned the term procedural program in Chapter 4. It is possible to write procedural programs as one long series of steps. However, by now you should appreciate the benefits of modularization, or breaking programs into reasonable units called modules, subroutines, functions, or methods. … Tip: You first learned the term modular in Chapter 2; you learned about abstraction in Chapter 3.
GUI programs are called event-based or event-driven because actions occur based on user-initiated events such as clicking a mouse button. When you program with event-driven languages, the emphasis is on the objects that the user can manipulate, such as buttons and menus, and on the events the user can initiate with those objects, such as clicking or double-clicking. The programmer writes instructions that correspond to each type of event. Event-driven programs require unique considerations for the programmer. The program logic you have developed so far for most of this book is procedural; each step occurs in the order the programmer determines. In a procedural program, if you issue a prompt and a statement to read the user’s response, you have no control over how much time the user takes to enter a response, but you do control the sequence of events—the processing goes no further until the input is completed. In contrast, with event-driven programs, the user might initiate any number of events in any order. For example, if you use a word processing program, you have dozens of choices at your disposal at any moment. You can type words, select text with the mouse, click a button to change text to bold or to italics, choose a menu item, and so on. With each word processing document you create, you choose options in any order that seems appropriate at the time. The word processing program must be ready to respond to any event you initiate. With an event-driven program, a component from which an event is generated is the source of the event. A button that a user can click is an example of a source; a text field that one can use to enter text is another source. An object that is “interested in” an event you want to respond to is a listener. It “listens for” events so it knows when to respond. Not all objects can receive all events—you probably have used programs in which clicking on many areas of the screen has no effect at all. If you want an object, such as a button, to be a listener for an event such as a mouse click, you must write the appropriate program statements. Although event-based programming is relatively new, the instructions that programmers write to correspond to events are still simply sequences, selections, and loops. Event-driven programs still declare variables, use arrays, and contain all the attributes of their procedural-program ancestors. An event-based program may contain components with labels like “Sort Records”, “Merge Files”, or “Total Transactions”. The programming logic you use when writing code for each of these processes is the same logic you have learned throughout this book. Writing event-driven programs simply involves thinking of possible events as the modules that constitute the program. Tip: In object-oriented languages, the procedural modules that depend on user-initiated events are often called scripts. Download 210.5 Kb. Share with your friends:
|