Identify what you want the program to do. The first step is fairly easy (because it’s always easy to tell someone else what to do).
Tell the computer, step by step, how to do what you want it to do. The second (and much harder) step is to figure out how to achieve your desired result. This process of telling the computer what to do, step by step, is what programming is really all about regardless of the programming language you ultimately use.
Every program organizes most of its instructions sequentially, but few programs organize all of their instructions sequentially. The reason is that if a program organizes all of its instructions sequentially, the program can run through its instructions exactly once before it stops.
Such a program might be handy for creating simple programs that print I am a useless program on-screen, but such programs ignore any data they might receive from the user. No matter how many times you press a key or click the mouse, running the following two-line code always displays : I am a useless program
Because this is all I can do
Writeln( ‘ I am a useless program ’); Writeln( ‘ Because this is all I can do ‘);
To make programs more useful and responsive, they need to accept and react to outside data.
When you play a video game and a monster appears on-screen, the game needs to react differently if you shoot and kill the monster or if the monster eats and kills you. If you shoot and kill the monster, the game lets you keep playing. If the monster kills and eats you, the game displays the words GAME OVER on-screen.
Branching instructions simply tell the computer to run different instructions depending on the value of certain data. When you delete a file, many programs ask, Do you really want to delete the file?. If you click the Yes button, the program follows the instructions to delete the file. If you click the No button, the program follows a different set of instructions,
Write(‘ Do you want to delete the file? (Y or N) ’); Read(answer); IF answer = ‘Y’ THEN writeln (‘Deleting file’ ) ELSE writeln (‘File NOT deleted’);
procedure GoPassword; // SUB PROGRAM var password : string; Begin WHILE password <> 'open' Do begin Writeln('Enter your password'); read(password); IF password = 'open'THEN Writeln( 'Welcome to the FBI''s secret computer network') ELSE Writeln('TRY AGAIN'); end; end; BEGIN // MAIN PROGRAM GoPassword; readln; END.
By dividing a single program into subprograms, you gain the following advantages :
Subprograms divide a large program into smaller parts to make reading and writing large programs easier.
Subprograms isolate related program instructions . So if you need to modify a program later, you just need to modify a subprogram, much like removing a defective brick from a wall and putting in a better one
A second advantage is that storing subprograms in separate files also lets you reuse subprograms. By storing commonly used subprograms in files , you can create libraries of useful subprograms , copy them to another computer, and reuse them in other programs.
If programmers found a subprogram library useful, they often copied it for their own programs . Unfortunately, this meant that you had multiple copies of the same subprogram library. If you found a mistake in your subprogram library and fixed it, guess what? Now you’d have to find and fix that same mistake in every single copy of that same subprogram library.
Programmers often copied a useful subprogram library and then added their own subprograms to that library file, which meant that you not only had multiple copies of a subprogram library, but you could also have slightly different versions of that same subprogram library scattered among multiple programmers.
To solve these twin problems, computer scientists invented something called object-oriented programming (OOP)
Object-Oriented programming (OOP) OR “Oops, you spent four years studying the wrong programming language in college ??? ”. …just kidding…
Dividing programs into objects The basic idea behind objects is that instead of making physical (duplicate) copies of subprograms, you maintain a single, physical copy of subprograms but allow others to make “virtual” copies of those subprograms,
If programmers need a subprogram to fix a problem, they need to modify only the original subprogram stored in an object. This automatically updates any virtual copies of the subprogram anywhere else in the program.