- Introduction (1 minute)
- Cooper's Quick History of Programming (6 minutes)
- The World of Objects (3 minutes)
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The World of Objects (3 minutes)
The problem with procedural languages is that they're usually tied very closely to the operating system they run on, and back in the old days this meant that they were tied even more closely to the hardware. As languages began to overcome this obstacle, they become more sophisticated and more popular. For instance, a macro language was very machine-specific. An IBM macro program simply couldn't run on a DEC VAX, and vice versa. By the time C came along, it could run on anything, but the compilers still had to be machine-specific. If a C program was written on an IBM machine, it still had to be compiled with a VAX compiler if it was going to run on a VAX. Each machine simply had its own way of defining and addressing "real" memory.
The UNIX operating system did away with all this, since the operating system and its main programming language, "C," were one and the same. Pure UNIX was written in pure "C" and could be compiled with the same C compiler that came with every UNIX system. Although each manufacturer used or created a different "flavor" of UNIX, they all pretty much held true to this "open" standard. This meant that programmers could now develop programs without having to tailor them for specific machines. Programmers could concentrate solely on data and its interactions, and not be concerned with "physical" details. In short, working entirely in the abstract, programmers could now view both data and processes as discrete objects.
Although data is stored and processed in pretty much the same way as it always has been, once we're freed of having to understand "how" the data is stored, we can concentrate on the various things we can do with it. For instance, it's not just discrete data such as name, phone number, and address that are labeled and given a distinct location in a computer memory; you can do the same thing with the procedures that act on the data. Suppose a variable name (regardless of the language) is stored in the location x000FFF678. The programmer simply writes the code statement string name. It's up to the operating system, in combination with the language compiler, to associate a hexadecimal number with the ASCII string name. However, it's just as easy to do the same thing with a procedure: getname(). Although getname() is a series of statements and not a single entity, it's declared just like a variable or constant and therefore is stored like one, say at location x00099ADF. The next logical step is to simply gather the declaration of a variable and any procedures associated with it into some convenient bundle, and voilà! We now have the basics of an object-oriented language.
Since this process is basically conceptual and not defined by any physical or mathematical bounds, most programming languages can create programmable objects. In fact, C++ is simply the C programming language using its existing constructs to define a "new" language. Throughout the 1990s, object-oriented concepts became popular with software engineers, designers, and programmers because of OOP's ability to create and manage large applications. With object definitions being designed into the application, objects could be reused repeatedly without rewriting. In addition, the biggest problem with "modular" programming languages was that no matter how small a change is made, the entire program must be recompiled at some point. By the mid 1990s, some IT departments had applications with lines of code running into the millions! Even with the fastest processor, this much code takes quite a bit of time to compile. On top of that, fixing the code for one bug could generate innumerable additional bugs, and fixing these then propagated even more bugs, ad infinitum! Maintaining older applications in now esoteric languages such as COBOL and Pascal was hard enough, but the problems of maintaining even new applications in languages such as C were beginning to mount.
With object-oriented design, large applications are broken into smaller pseudo-applications containing objects and the procedures (methods) that relate to them. These objects can precisely encompass all the rules required for running some aspect of the core business. If any business rule changes for any reason, only the objects that implement that business rule—not the entire application—would need to change. This puts a bit of extra burden on the designers and architects for these types of applications, but if designed well such applications are exponentially easier to maintain over time.