Every program consists of one or more commands (instructions), and each command is a line of code or a statement. The more lines of code, the more complicated the program.

Each command tells the computer to do one thing. Put enough commands together and you can create a simple program, as shown in Figure 1-1.

Figure II.1-1. If you put enough commands together, you can create any type of program.

Every programming language provides a list of commands dubbed keywords or reserved words. By typing keywords one after another, you can tell the computer what to do.

A programming language's keywords act like the letters of the alphabet. Type letters in different combinations and you can create different words. Type keywords in different combinations and you can create different commands, as shown in Figure 1-2.

Figure II.1-2. Multiple keywords, along with various symbol characters, can create a single command.

Every program consists of one or more commands, but there are different types of commands. Some commands tell the computer how to manipulate data, such as adding two numbers together. Other commands might tell the computer how to print data, display it on-screen, or save it on a disk.

Although you could jumble all your commands together and still have a working program (see Book 1, Chapter 2 for more on programs), make your program easier to read and modify by organizing similar commands in different parts of your program.

So if your program isn't printing correctly, you don't have to search through your entire program to find the faulty commands. Instead, you can just look at the part of your program where you grouped all your printing commands, as shown in Figure 1-3.

Figure II.1-3. Dividing a large program into parts can make it easy to find specific commands in your program.

When you write a simple program that consists of a handful of commands, organizing related commands in groups isn't too important, but when you start writing bigger programs that consist of hundreds or thousands of commands, organizing commands can mean the difference between writing a program that nobody can understand or a program that's easy for anyone to understand and modify.

When you save your program, you save it as a single file on the computer. However, the more commands you write, the bigger your program gets, and the bigger the file you need to store the whole program.

No matter how carefully you organize your commands, eventually your program will get too big and cumbersome as a single massive file to read and modify easily. That's when you need to break your program into smaller parts.

The smaller the program, the easier it is to write, read, and modify later. So rather than create a massive program, with related commands organized into groups, you can divide a large program into smaller pieces, or subprograms.

Subprograms essentially break up a large program into multiple miniature programs with each miniature program acting like a building block to create a much larger program, as shown in Figure 1-4. So rather than build a large program entirely out of keywords, you can build a program out of keywords and subprograms (which are themselves made up of keywords).

Figure II.1-4. Subprograms create reusable building blocks that you can use to make writing programs even easier.

Using keywords alone to create a program is like trying to build a skyscraper out of bricks. It's possible, but it takes a long time to layer enough bricks to reach the height of a typical 50-story skyscraper.

Using subprograms to create a larger program is like using I-beams to build a skyscraper. Essentially, I-beams act like bigger bricks the same way that subprograms act like bigger building blocks than keywords by themselves.

You can store subprograms in two places:

Storing subprograms in the same file is no different than grouping related commands together in one file. This is like storing your socks, underwear, and shirts in the same drawer but pushing them into separate corners. The drawer may be organized, but such an arrangement is suitable only if you don't have many clothes to worry about. The moment you get more clothes, you need a bigger drawer to hold it all.

The same holds true with storing subprograms in a single file. Eventually, if you group enough commands into subprograms, a single file crammed full of subprograms can still be cumbersome to read and modify.

To keep files down to a reasonable size, programmers store subprograms in separate files, as shown in Figure 1-5. Not only does this avoid cramming everything into a single file, but separate files also give you the option of creating reusable libraries of subprograms that you can copy and reuse in another program.

Programmers often sell their libraries of subprograms to others, although each library of subprograms is usually designed to work only with a specific programming language and operating system, such as C++ running on Windows. Many Windows libraries of subprograms are stored as dynamic link libraries (DLL) although you may see some libraries sold as something called ActiveX controls or .NET components.

The name simply tells you what type of programming languages and computers you can use the programming library on. So if you're using a programming language that can use ActiveX controls, you can buy third-party libraries of subprograms stored as ActiveX controls. If you're using a programming language that can use .NET components, you can use subprogram libraries stored as .NET components.

Figure II.1-5. Storing subprograms in separate files can make it easy to read and modify one part of a large program without having to see any other part of that same program.

By storing subprograms in separate files, you can write a program with multiple programming languages. That way you can write your main program in BASIC and then write subprograms in C or Java. By doing this, you don't have to limit yourself to the strengths and weaknesses of a single programming language. Instead, you can take advantage of the strengths of each programming language.

If you're writing a hard disk diagnostic program, you could write the whole thing in C because C is great for accessing the hardware of a computer. However, you may find that C is too clumsy for printing reports or displaying information on-screen. In that case, what are your choices? You can

By giving you the option to choose the best programming language for a specific task, subprograms help make it easier for you to write larger programs, as shown in Figure 1-6.

Figure II.1-6. Subprograms give you the option of using different programming languages to write different parts of a larger program.

The more complicated programs get, the larger they get. If programs get too big, they get harder to write, understand, and modify. This is why dividing a large program into multiple smaller subprograms can make programming much easier. Just write a bunch of little programs and then paste them together to create a bigger program.

Unfortunately, dividing a large program into subprograms isn't without its problems:

Figure II.1-7. Changing one part of a program can affect other parts of that same program.

To enforce weak coupling, computer scientists have created object-oriented programming (OOP). The main idea behind OOP is to divide a large program into objects.

Objects act like "super" subprograms. Whereas subprograms give programmers the choice of making a tightly or loosely coupled subprogram, objects force programmers to create loosely coupled subprograms.

By forcing programmers to create loosely coupled subprograms, objects make it easy to modify a program without worrying about any unintended side effects. OOP lets you yank out an object, modify it, and plug it back in without worrying if your changes might affect the rest of the program.

Objects offer another advantage over subprograms. Whereas subprograms typically represent a specific action, objects represent specific physical items in the real world.

For example, if you're writing a program to control a robot, you could divide the program into the following subprograms that make the robot:

If you're using OOP, you could divide that same program into objects that represent the robot's

The way you divide a large program into parts isn't important. What's important is how easy it is to modify those separate parts later. Suppose you rip the legs off your robot and replace them with treads. In an OOP, you can yank out the Legs object and replace it with a Treads object, as shown in Figure 1-8.

First use of "Sub programs" needs to be one word in the first paragraph of the artwork. Also, shouldn't "real world components" be hyphenated to be "real-world components"?

Figure II.1-8. Object-oriented programming divides your program into logical parts that correspond to the real world.

Although the robot now uses treads instead of legs to move, the Brain object can still give the same type of commands to make the robot move, such as Move Forward, Move Backward, and Stop.

How do you change the equivalent program divided into subprograms? First, you have to change the Move subprogram to reflect the change in movement from legs to treads. Then you may need to change the Navigate subprogram so it knows how to navigate in different directions with treads instead of legs. Finally, make sure the changes you make in the Navigate and Move subprograms don't accidentally affect the Sense subprogram.

Sounds like a lot of work just to make a simple change? It is, and that's why loose coupling between subprograms is so important. Because programmers can't always be trusted to make sure their subprograms are loosely coupling, OOP forces them to do it whether they like it or not.

The three actions of most programs are

A football-picking program takes in data about both teams, uses a formula to predict a winner, and prints or displays its answer on-screen. A hotel reservation program gets a request for a room from the user (hotel clerk), scans its list of rooms for one that's available and that matches the user's criteria (no smoking, two beds, and so on), and displays that result on-screen.

Basically, every program takes in data, calculates a result, and displays that result. To accept data from the user and display a result back to the user again, every program needs a user interface, as shown in Figure 1-9.

Figure II.1-9. The user interface accepts data and displays the results of its calculations back to the user.

To create a program, you have to create both your program and your user interface. The user interface acts like a middleman between the user and the program. Here are three common ways to create a user interface:

Creating your own user interface takes time to write and even more time to test. Although nothing's wrong with creating your own user interface, the time spent creating a user interface could be better spent writing your actual program. For that reason, few programmers create their own user interfaces unless they have special needs, such as designing a user interface to be used by blind or disabled users.

Because creating a user interface can be so troublesome and most user interfaces look alike anyway, some programmers create libraries of subprograms that do nothing but create a user interface. That way you can create your program, slap on the user interface by adding the library of subprograms, and have a finished program.

Because nearly every program needs a user interface, and most user interfaces look the same anyway (at least on the same operating systems, such as Windows or Mac OS X), programmers have created RAD tools that simplify creating user interfaces, as shown in Figure 1-10.

The RAD tool creates your user interface so that all you need to do is write commands to make your program work with that user interface.

In general, the more complicated the problem you want the computer to solve, the larger and more complicated your program is. To manage a large program, programmers divide a large program into subprograms or objects.

Of course, it's entirely possible to write a great program crammed into a single file with commands scattered all over the place, but such a program is difficult to modify later. You can also divide a program into subprograms and objects and still wind up with a program that doesn't work.

Figure II.1-10. Creating a user interface involves picking common items, such as buttons and check boxes, and then drawing them on a window.

In the end, the only result that matters is whether the program does what it's supposed to do. If you can create programs that work on a consistent basis, you're not only a successful programmer but probably a highly paid one as well.