more event handlers for your UI, you have a complete working UI. Now you just have to attach this UI to a working program.
Writing your program
Some people write the program first and then design a UI around it. Other people design the UI first and then write the program to work with it. The whole point of event-driven programming is to separate your program from your UI so you can focus on making each part work individually.
Event-driven programming focuses mostly on designing a UI and making it work, but it does little to help you write your actual program. To write your program, you can use structured programming or object-oriented programming (or both, or neither).
After you’ve written your program, you “attach” the program to your UI by writing event handlers. Event handlers “glue” your UI to your actual program. With event-driven programming, you can be pretty sure that your UI will always work perfectly. You just have to worry about errors in your main program.
Object-Oriented Programming
Structured programming helps you organize and divide your program into smaller, more manageable pieces. For small to medium programs, dividing a program into smaller programs is fine, but the larger your program gets, the more smaller programs you’ll have to worry about. Eventually, computer scientists discovered that they needed another technique for dividing large programs into parts. They called this new technique object-oriented programming (often abbreviated as OOP). Object-oriented programming solves two glaring problems with structured programming: reusability and modeling.
Reusability means that you can collect smaller programs that work together, store them in a larger group called an object, and then plug those objects into different programs like LEGO building blocks. Where structured programming encourages reusability by letting you reuse subprograms, object-oriented programming encourages reusability on a larger scale by letting you reuse objects (which contain multiple smaller programs). Reusing individual subprograms is like using bricks to build a house. Reusing objects is more like using premanufactured walls to build a house.
Modeling means making the parts of a program more intuitive. One of the reasons why assembly language is so hard to understand is because manipulating data in the processor’s registers has nothing to do with solving problems like adding two numbers together. Likewise, dividing a large program into smaller tasks, using structured programming, does nothing to help you understand the actual problem the program is trying to solve.
With modeling, you divide a problem into real-life objects. If you were writing a program to control a car, one object might be the steering mechanism, another object might be the braking mechanism, and a third object might be the electrical system. By making each part of a program (each object) model a real-life object, it can be far easier to understand the purposes of the different parts of a program and how they work together.
For example, suppose you had to write a program to land a rocket on the Moon. This is how you might write this program using structured programming:
Land a rocket on the Moon Launch rocket Guide rocket through space Find a landing area on the Moon Put rocket down on landing area
So far, structured programming seems logical, but what happens when you keep dividing tasks into smaller tasks? Just focusing on the Guide rocket through space task, you might wind up with the following:
Guide rocket through space Get current coordinates Compare current coordinates with Moon coordinates Adjust direction
Dividing the Adjust direction task into smaller tasks, you might get this:
Adjust direction Identify current speed and direction Determine angle needed to steer toward the Moon Fire thrusters to change the angle of the rocket
Notice that the deeper you keep dividing tasks, the more removed you get from knowing what the main purpose of the program may be. Just by looking at the task Identify current speed and direction, you have no idea whether this task involves flying a rocket to the Moon, driving a car down a road, or controlling a walking robot to an electric outlet to recharge its batteries.
The more you divide a larger task into smaller tasks, the harder it can be to understand what problem you're even trying to solve. This gets even worse when you start writing actual program commands.
The two parts of most programs are the commands that tell the computer what to do and the data that the program manipulates. So, if you wrote a program to identify the current speed and direction of a rocket, the commands would tell the computer how to retrieve this information, and the speed and direction would be the actual data the program uses.
Essentially, program commands are separate from the data they manipulate. If one part of a program manipulates data incorrectly, the rest of the program winds up using that contaminated data and you, as the programmer, won’t know which part of the program screwed up the data. This is like sitting in a baseball game, ordering a hot dog from a vendor, and having six people pass your hot dog down to you. When you see fingerprints all over your hot dog, can you tell which person touched your food?
Isolating data
Object-oriented programming avoids the problem of not knowing the purpose of code by combining data and the commands that manipulate them into a single entity called (surprise!) an object. With a well-designed object-oriented program, each object models part of the real-life problem so it’s easier to understand the purpose of the code inside that object.
So, if you were designing a program to launch a rocket to the Moon, object-oriented programming would let you divide the program into objects. One object might be the rocket, a second object might be the Moon, and a third object might be the Earth.
You can also divide a large object into smaller ones. So the rocket object might be divided into an engine object and a guidance object. The engine object could be further divided into a fuel pump object, a nozzle object, and a fuel tank object.
Suppose you wrote a program to calculate a rocket's trajectory to the Moon, and the engineers suddenly designed the rocket with a more powerful engine? With object-oriented programming, you could just yank the engine object out of your program, rewrite or replace it, and plug it back into the program again.
In structured programming, modifying the program to reflect a new rocket engine would mean finding the program commands that manipulate the data that represents the engine’s thrust, and then making sure that new data gets fed into the program at the proper location and still works with any other program commands that also handle that same data. (If the explanation in this paragraph sounded confusing and convoluted to you, that just shows you the less-than-intuitive problem of modifying a structured program versus an object-oriented program.)
Simplifying modifications
Besides organizing a large program into logical pieces, objects have another purpose: code reusability. In school, it was always easier to copy someone else’s homework than it was to do it yourself. Similarly, programmers find that it’s easier to copy and reuse somebody else’s program rather than write their own program from scratch.
In structured programming, you could divide a large program into subprograms and then store those subprograms in a separate file. Now you could copy that file to reuse those subprograms in another program.
Copying subprograms makes programming easier, but here are two problems:
What if you copy a subprogram and then later find an error in that subprogram? Now you have to fix that subprogram in every copy. If you made 17 copies of a subprogram, you’d have to fix the same error 17 times in 17 different copies of the same