Whitepaper German

Objects simplify modifications Besides organizing a large program into logical pieces, objects have another purpose — code reusability. Just as in high school, it was always easier to copy someone else’s homework rather than do it yourself, so programmers find that it’s easier to copy and reuse somebody else’s program rather than write their own 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’ll have to fix that subprogram in every copy.

If you made 17 copies of a subprogram, you’ll have to fix the same error 17 times in 17 different copies of the same subprogram. ✦ What if you want to modify and improve a subprogram? Suppose you find a subprogram that asks the user to type in a password of no more than 10 characters, but you want your program to allow users to type in passwords up to 25 characters. At this point, you could either • Write your own password-verifying subprogram from scratch (which would take time). • Copy the existing subprogram and modify it (which would take much less time).

It’s easier to make a copy of an existing subprogram and then modify this copy. Now you’ll have two copies of (almost) the same subprogram, but uh oh! Suddenly, you discover an error in the original subprogram. Once again, you have to correct this error in the original subprogram and also in the modified subprogram. If you made 20 different modifications to a subprogram, you now have the problem of not only correcting the error in every copy of the original subprogram, but also fixing that same error in all your modified versions of that original subprogram.