In a ride-sharing system's design, why should fare strategy (standard, shared, luxury) and vehicle type (car, bike) be modeled as two separate hierarchies instead of one combined hierarchy?
They vary along genuinely independent axes: which vehicle got assigned to a ride has nothing to do with which pricing scheme the passenger selected, and any vehicle can legitimately be combined with any pricing scheme -- a bike under a luxury strategy, a car under a shared strategy, both are meaningful. Combining them into one hierarchy, such as a LuxuryCarFare and a SharedBikeFare class for every combination, would need a class per pairing, growing multiplicatively as either vehicle types or pricing schemes are added. Keeping Vehicle and FareStrategy as two separate hierarchies, connected only where a Ride computes its fare by calling the strategy with the vehicle as an argument, means either dimension can grow independently without touching the other, and any combination of the two just works automatically.
Ready to master this question?
Generate a complete walkthrough — background, the full answer in plain language, a working code example explained line by line, a real-world scenario, common mistakes, and how this same question gets asked in different ways.
Sign in to generate a response