Roulette: Inheritance Case Study What are scenarios? ● Roulette involves a player, a wheel, and bets ● User/player given choice of bet � Real game has several players, we’ll use one � Bet choice made � Real game has lots of kinds of bets, we’ll use three but � Wager made make it simple to add more � Wheel spins � Payoff given ● Instead of brainstorming classes, we’ll take as given: � Play again? � Wheel � Bet ● What happens when player bets? � Bankroll � What’s recorded? � Roulette (game) � How is winning determined? � What’s missing? � What about multiple players, multiple bets? � What are responsibilities, collaborations? Duke CPS 108 8.1 Duke CPS 108 8.2 What is a bet? Roulette Class Diagram ● Has-a relationship ● Difference between wager and bet � Bet has a wheel, how/why? � Bet contains wager amount � BetFactory has bets � Different bets have different payoffs � What bets? � Game has a bankroll � Does this make sense? ● What happens after the wheel rolls and payoff occurs? ● Uses-a relationship if (myBet == redblack) … � Parameters else if (myBet == oddeven) … � Return values � Local variables � Problems with this? � Open closed principle? Has-a relationship ● � Inheritance, use-as-a � Canonical OO tenet: avoid chains of if/else (when you can) � Substitutable for-a 8.3 8.4 Duke CPS 108 Duke CPS 108
Inheritance guidelines in C++ Designing hyperwag ● Inherit from Abstract Base Classes (ABC) ● Keep classes small and cohesive � one pure virtual function needed (=0) � as simple as possible, but no simpler � must have virtual destructor implemented � member functions should also be small � can have pure virtual destructor implemented, but not normally needed ● Design for change ● Avoid protected data, but sometimes this isn’t possible � specifications, requirements, design � data is private, subclasses have it, can’t access it � example: other formats for table design? � keep protected data to a minimum ● Single inheritance, assume most functions are virtual ● Design first, code second, but revisit design � multiple inheritance ok when using ABC, problem with ● Know the language, but don’t let the language rule the design data in super classes ● Get the classes right, concentrate on what not how � virtual: some overhead, but open/closed principle intact Duke CPS 108 8.5 Duke CPS 108 8.6 One view of hyperwag Patterns: Abstract Factory ● Abstract Factory/Factory aka “kit” � system should be independent of how products created � system should be configured with one of multiple products (or families of products, e.g., Win95, Motif) � you want to provide a class library of products and reveal interfaces but not implementations ● Consequences � factory encapsulates responsibility and process of creating objects, clients only see abstract interface. “Real names” hidden in factory � supporting new products can be difficult depending on the situation (but see Prototype pattern) ● Often want only one factory accessible in a program 8.7 8.8 Duke CPS 108 Duke CPS 108
Patterns: Singleton Patterns: Prototype ● Singleton ● Use a prototypical instance to clone new objects � classes used in a program can be specified/loaded at � enforce exactly one instance of a class, accessible in a well- runtime defined manner � avoid hierarchy of factories that parallels hierarcy of � possible to extend via inheritance classes ● Consequences ● Abstract Prototype class implements clone() � controlled access to single instance, e.g., � how to copy? deep vs. shallow Foo * foo = Foo::getInstance(); � how to initialize clones in subclasses � no global variables � no need to rely solely on class/static functions ● Managing Prototypes � use a factory or a prototype manager with registered ● Implementation prototypes � private constructor � cloning can be tough (e.g., circular references) � getInstance (or other class/static functions, see hyperwag) Duke CPS 108 8.9 Duke CPS 108 8.10
Recommend
More recommend
