|only for RuBoard|
If you are lucky, you are part of a programming team that places a premium on design. You know that a good design results in lower software development costs over time, which ultimately means a paycheck for you. Good programmers know that the cost of writing software cannot outweigh the benefit it yields; you must be profitable. A good design is critical. Fortunately, a perfect initial design is not critical. In fact, perfection rarely occurs, if it happens at all. A good design is arrived at over time.
Usually, after running headfirst into the code and writing several classes, you begin to see patterns. You might notice that several classes share the same kind of data and exhibit the same behavior. You might find that you can group this data and behavior into one class. This scenario is called generalization . Usually, generalizations are discovered after the factthe derived classes are written first and the base class is determined last. You can think of this process, refactoring , as retroactive OOP.
Refactoring is somewhat contrary to the idea of specialization , in which class hierarchies are derived over several versions of an application to handle special cases. For example, in Version 1.0 of your application, Employee might have been sufficient to handle all company employees . Over time, though, it became necessary to create derived classes based on Employee to handle the following new situations that did not exist when the application was first written:
Rather than use a contrived example involving geometry seen in most OOP books, we instead will use a contrived example involving payments in an Internet commerce setting (which is much cooler than squares and circles). And if you squint, the examples will almost seem like real-life code. But just in case you are one of those people that think real OOP books must use examples with shapes , you will find such an example at the end of the chapter.
|only for RuBoard|