Event-Driven Programming: Introduction, Tutorial, History (Stephen Ferg 著)

Introduction (已看)

In The Beginning - Transaction Analysis (已看)

The Handlers Design Pattern 

Frameworks

GUI programming

Maintaining State

Conclusion

Introduction

One effective way to explain a complex idea is to tell the story of its life. 

In The Beginning - Transaction Analysis

　　Dataflow Diagrams

Structured analysis used dataflow diagrams (DFDs) to show the logical structure of a computer system.

On a DFD, a record in a sequential file was coneptualized as a packet of data moving through a pipeline, or along a conveyor belt, called a dataflow. Packets passed through a sequence of workstations called processes where they were filtered, used, enhanced, or transformed, and then passed on to the next workstation. 

Describing a system in this way was called transform analysis.

De Macro also briefly described a second kind of analysis called transaction analysis and provided this diagram.

He explained the differences between transform and transaction analysis this way

• Transform analysis applies to applicatios that are transforms - that is, application that have clearly identified input streams, central processing, and output streams. A transform is represented in Data Flow Diagram terms by a linear network
• Transaction analysis applies to transaction centers, parts of the application characterized by sudden parallelism of data flow

"Transaction analysis", Yourdon and Constantine wrote, "is suggested by data flow graphs resembling Fig. 11.1 - that is, where a transform splits an input data stream into serveral discrete output sub-streams." Here is Figure 11.1, It is the archetype digrams of event-driven programming.

A transaction, they said, begins when "any element of data, control, signal, event, or change of state" is sent to the transaction center process.

A transaction center of a system must be able to

• get (obtain and respond to) transactions in a raw form
• analyze each transaction to determine its type
• dispatch on type of transaction
• complete the processing of each transaction

　　Structure Charts

A dataflow diagram shows the logical functions that a system must perform, but it doesn‘t say anything about the design of the program that will perform those functions. In structured analysis and design, a different diagram called a structure chart was used to show program design. On structure charts,  

The Handlers Design Pattern

If Yourdon and Constantine were writing today, they might very well call their notation of transaction analysis a design pattern. I will call it Handlers pattern.

On the diagram you can see:

• a stream of data items called events (Yourdon and Constantine‘s "transactions")
• a dispatcher (Yourdon and Constantine‘s "transaction center")
• a set of handlers

　　The Headless Handlers Pattern

　　The Extended Handlers Pattern

　　The Event Queue

　　Some Examples of the Handlers Pattern

　　Objects

　　Systems

　　Client-Server Architecture

　　Messaging System

Frameworks

　　Object-Oriented Event-Driven Programming

　　Frameworks

　　SAX - an example of a framework

　　Why programming with a framework is hard

GUI programming

　　Why GUI programming is hard

　　The Observer Pattern

　　Event Objects

　　The Registered Handlers pattern in GUI applications

　　Registering Event-Handlers in Python - "binding"

　　Registering Event-Handlers in Java - "listeners"

　　Callback programming

　　GUI programming - summary

Maintaining State

　　Rejecting invalid transactions

　　State Machines

　　Coding a Finite State Machine(1)

　　Coding a Finite State Machine(2)

　　Ways to remeber state

Conclusion

Event-Driven Programming: Introduction, Tutorial, History (Stephen Ferg 著)

原文：https://www.cnblogs.com/revoid/p/9185984.html