Читать книгу Beginning Programming All-in-One For Dummies - Wallace Wang - Страница 39

In the early days, using a program was fairly simple. After you typed the command to run a particular program, that program might ask a question such as

What is your name?

At this point, you had no choice but to type a name, such as Charlie Smith. After you typed in your name, the program might respond with

Hello, Charlie Smith. What month were you born?

The moment you typed in a month, such as April, the program might respond:

What day were you born?

And so on. If you wanted to type your day of birth before your month of birth, you couldn't because the program controlled your options.

Not surprisingly, using a computer like this was frustrating to most people, so computer scientists soon invented something called a graphical user interface (GUI). A GUI displays multiple options to the user in the form of drop-down lists, windows, buttons, and check boxes. Suddenly, instead of the computer dictating what the user could do at any given time, the user could tell the computer what to do at any given time, just by choosing one of many available commands.

Forcing each program to display menus and windows had two advantages for users:

 It made using a computer much easier. Instead of having to type in commands, users could just click the command they wanted to use.

 It’s fairly easy to figure out how to use different types of programs. After you understand that you can choose the Print command from the File menu, you know how to print in any program — whether it’s a word processor, a database, or an image-editing program.

Unfortunately, although drop-down lists made programs easy for users, they made writing programs much harder for programmers:

 Programmers had to write extra commands just to display all these fancy drop-down lists and windows. (Even worse, programmers had to make sure all those extra commands used to create drop-down lists and windows actually worked correctly.)

 Programmers now had to write programs that could react to whatever command the user chose. Instead of presenting the user with options in a specific, predictable order, programs had to handle the unpredictable choices of the user.

To solve this dual problem of creating drop-down lists and knowing how to handle the different commands the user may choose at any given time, computer scientists developed event-driven programming.

In event-driven programming, an event is something that the user does or that the computer must respond to. The user might click a drop-down list or click a button displayed in a window. The computer might need to respond to an incoming email or a file being added to a directory. Event-driven programming simply focuses on displaying different commands onscreen and then handling these different events when they occur.

Event-driven programming divides programming into three distinct parts:

 The user interface (UI): The commands the user sees onscreen

 The event handler: The part of the program that reacts to the commands the user chooses from the UI

 The actual program: The part of the program that actually does something useful, such as drawing pictures or predicting the winners of horse races

In the old days, creating a UI essentially tripled a programmer’s work. You had to:

1 Write your program.

2 Write commands to create a UI.

3 Write commands to make your UI actually work.

Instead of forcing you to write commands to display drop-down lists and windows onscreen, a tool called a rapid application development (RAD) program lets you visually design your UI, such as the number, placement, and size of buttons.

After you’ve designed your UI (without having to write a single command to do it), you can write short programs that respond to everything the user could possibly do, which is called an event. If the user clicks a drop-down list, that’s an event. If the user clicks a button in a window, that’s a different event. When you write a small program to handle an event, the program is called an event handler.

Without event-driven programming, you’d be forced to write commands to create a UI and more commands to make the UI work. With event-driven programming, you just have to write commands to make your UI work. The fewer commands you have to write, the faster you can create a program and the easier the program will be to read, understand, and modify later.

The most popular language that defined event-driven programming is Visual Basic although other languages have adopted event-driven programming as well.

Event-driven programming doesn’t replace structured programming; it supplements it. Structured programming techniques are useful for helping you write your program. Event-driven programming is useful for helping you design a UI for your program.

Basically, event-driven programming divides programming into three distinct steps: designing the UI, writing event handlers to make the UI work, and writing the actual program.