Beginning Programming All-in-One For Dummies. Wallace Wang
if you wanted 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 eitherWrite 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 the copy. Now you 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 would 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.
But after you modify a subprogram, will you remember which subprogram you copied and modified originally? Even worse, you could copy a subprogram and modify it, and then copy your modified subprogram and modify that copy. Do this several times and you’ll wind up with several slightly different versions of the same subprogram, but now you may not have any idea which subprogram you copied originally.
So, now if you find an error in the original subprogram, how can you find and fix that same error in any modified copies of that subprogram? Most likely, you can’t because you won’t know for sure which modified versions of the subprogram you (or another programmer) might have created.
Because programmers are always going to copy an existing program that works, object-oriented programming helps manage the copying process by using inheritance. The whole idea behind inheritance is that instead of making physical copies of code, you have only one copy of code (called a class) at all times.
Instead of physically copying all the code stored in a class, objects inherit all the code in a class by essentially pointing to the subprogram that they want to copy. This saves physical space by eliminating the need to make multiple copies of the same code.
Now instead of copying code (and risking creating duplicate copies), you can reuse existing code and add your own code. Now you can build more complicated programs by reusing existing objects like building blocks. If you modify code in one class, that modification automatically appears in any classes that inherit from that original class, as shown in Figure 2-8.
FIGURE 2-8: Object-oriented programming never physically copies code but “points to” or “inherits” code.
Object-oriented programming makes programs easier to write (by dividing a large program into parts), easier to understand (by organizing code into classes that mimic the actual problem the program is trying to solve), and easier to modify (by automatically updating any copies of code). All these advantages allow you, as the programmer, to focus more on solving problems and less on keeping track of trivial details.
Using Protocol-Oriented Programming
As computer scientists started using object-oriented programming techniques, they noticed the same limitations. Object-oriented programming encapsulates variables (properties) and functions (methods) that manipulate that data to model real-life objects like an engine. Object-oriented programming made it easy to copy and reuse code, but it also added complexity by creating objects that inherited more and more code that often wasn’t needed.
To help minimize the needless copying of code that would ultimately be ignored or modified, computer scientists created protocol-oriented programming. The main difference is that when you use object-oriented programming, you must define the method names and code to make that method work. With protocol-oriented programming, you can simply define the method name without writing any code within that method at all.
The purpose of simply defining the method name without writing any actual code is to create uniform method names that can be reused by your code just like objects. However, the advantage is that each class can adopt or conform to a protocol but write its own code for a particular method. Where object-oriented programming forces you to copy method names and the code that you may not need, protocol-oriented programming lets you just copy method names and customize the code to make it work the way you want. This reduces complexity and increases flexibility.
Protocol-oriented programming isn’t meant to replace object-oriented programming; it’s meant to work with it. Sometimes you may want to use object-oriented programming, and sometimes you may want to use protocol-oriented programming. Protocol-oriented programming is simply a way to reduce the complexity inherent in object-oriented programming.
Design Patterns
Although every program is different, all programs tend to require similar types of solutions. Rather than force programmers to reinvent solutions, computer scientists have identified common solutions to specific types of problems. These common solutions are called design patterns.
The main idea behind a design pattern is to show the best way to solve a specific type of problem. By following these best practices defined by a design pattern, you can spend less time thinking about the optimal way to solve a problem and simply use a design pattern to guide you into solving that particular problem using any programming language.
Design patterns focus on solving three types of common programming problems:
Creational: Defines the best way to create classes for different purposes
Structural: Defines the best way to design classes
Behavioral: Defines the best way for classes to share data and communicate with each other
Think of design patterns as cookie cutters to help you structure your code without telling you specifically how to write that code. By using design patterns, you can (hopefully) spend less time designing the structure of your program and more time writing reliable code faster than before.
DESIGNING PROGRAMS WITH TODAY’S METHODOLOGY
Each step — from spaghetti programming, to structured programming, to event-driven programming, to object-oriented programming, to protocol-oriented programming, to design patterns — is meant to guide programmers into writing better-organized programs that can be modified quickly and easily. Today, object-oriented programming, protocol-oriented programming, and design patterns are popular, but tomorrow, another programming methodology will likely arrive to deal with the shortcomings of object-oriented programming, protocol-oriented programming, and design patterns.
You want to avoid spaghetti programming, but structured programming, event-driven programming, object-oriented programming, and protocol-oriented programming are often used in the same program. You may use object-oriented programming and protocol-oriented programming to divide a program into objects, and then use structured programming to organize the commands you write and store inside each object. Finally, you may use event-driven programming to design a fancy UI so people know how to use your program.
By using each programming methodology’s strengths, you can create a well-designed program, on time, that actually works. Given the track record of government agencies and Fortune 500 corporations, creating