Creating libraries of subprograms

January 30th, 2008 yudi Posted in Programming Structure No Comments »

When you divide a large program into a bunch of smaller programs, you’re doing nothing more than rearranging and organizing your instructions. Unfortunately, a large program written as one long list of instructions is barely any smaller than the same large program divided into multiple subprograms. Because the larger a program gets, the harder it can be to understand, programmers found a way to take subprograms out of the main program file and store them in separate files.

Now instead of a program consisting of a single, massive file, it can consist of two, three, or even several thousand separate files.

By storing subprograms in separate files, reading and understanding your program is much simpler. Instead of scrolling through one massive file that contains your main program and all of its subprograms, you can just open the file that contains the subprogram you want.

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.

One file might contain subprograms that calculate different mathematical equations, and a second file might contain subprograms that display graphics on-screen. By creating and reusing libraries of subprograms, you can keep your main program size to a minimum.

Technical Stuff If you ever look at the structure of a typical C++ program, you might see code that looks like this:


#include <stdio.h>
#include <iostream.h>
int main()
{
    return 0;
}

The two #include commands simply tell the computer to use (or include) the subprograms stored in the separate files named iostream.h and stdio.h.

AddThis Social Bookmark Button

Dividing programs into objects

January 30th, 2008 yudi Posted in Programming Structure No Comments »

Storing subprograms in separate files helps keep programs to a reasonable size while allowing programmers to share libraries of useful subprograms. Unfortunately, two problems arose with subprogram libraries:

  •  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 (often abbreviated as OOP, as in “Oops, you spent four years studying the wrong programming language in college”).

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.

The virtual copies of subprograms work exactly the same as any physical copies. The main advantage is that you can’t modify a virtual copy of a subprogram. This prevents five different programmers from copying a subprogram and making five different versions.

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.

If programmers want to create slightly different versions of a subprogram, they just need to create a copy of the virtual subprogram and then make any modifications, which is known as polymorphism. They can either add new instructions or over write any existing instructions stored in the original subprogram object.

Any changes made to a virtual subprogram won’t affect or modify the original subprogram. By sharing subprograms as objects, you gain two advantages:

  •  You store a single copy of subprograms that others can freely share. Updating a subprogram in one location automatically updates any virtual copies of that subprogram throughout an entire program.

  •  Others can modify any virtual subprograms without physically copying or altering the original subprogram.

For now, remember that object-oriented programming is just another way to help you create, organize, and maintain large programs without losing your mind.

Ultimately, the real purpose of any programming technique, whether it’s dividing a large program into multiple subprograms or using object-oriented programming techniques, is to make programming easier for you

AddThis Social Bookmark Button




eXTReMe Tracker