لطفا منتظر باشید ...
Understanding the Benefits of Rewriting
It sounds like the object-oriented approach is the way to go. However, do you really want to go back and rewrite a working program in another style? Is such an exercise worth the effort? Such an endeavor is most often worthwhile. First, you’re really not “rewriting” the code per se; it’s more a matter of “reorganizing” the code. It’s certainly a different task than figuring out how to make the die bounce or determining what equation is needed to select the next frame in the animation. You did all that work in the previous chapter, and you don’t need to repeat it.| Note | Another term for reorganizing existing code is refactoring. |
The idea of refactoring an existing program is often a “one-step-back-two-steps-forward” approach. Imagine for a moment that you refactor the die code into a class, and that class is working perfectly in this die-rolling program. If you can get to that point, then making two dice roll for the next game will be much easier. If you really want to think ahead (to what will be covered at the end of the chapter—no peeking!), imagine a class that encapsulates a set of dice bouncing around and that contains a simple property on the class to control the number of dice to display. Now that would be useful!
| Tip | The benefit of refactoring existing programs is so great that I’m going to restate it one more time: Don’t be afraid to rewrite code. |
Okay, that’s settled, so you’ll now rewrite the Guess the Die Roll program in a more object-oriented style, turning the die into a class. You’ll also add a few (small) features as you go—things you can reuse in future chapters and games. Then, you’ll once again take a step back to examine what you’ve got and decide if it’s good enough. (Here’s a hint: It won’t be.)
