Software Design3.1Battleship overviewz What are the use cases?¾ How does customer use the program?¾ What are scenarios as the game develops?¾ What parts of the "standard version" are good/bad?¾ What options might we want to have?z How will we design the program?¾ Brainstorm classes¾ Develop and test¾ Rethink design and use cases¾ Develop and test¾ …Software Design3.2Battleship classes, Freecell classesz What are the classes in the program? Behaviors?¾ Look for objects, how do they act? Nouns? Verbsz What about a Ship class? Behaviors/Responsibilities?¾ State? Mutable?¾ Comparison? Other games?¾ Is there any behavior?z What about CardPile classes, similarities? Differences?¾ FreeCell, AcePile, DrawPile, …¾ Other card games?Software Design3.3Inheritance (language independent)z First view: exploit common interfaces in programming¾ iterator, C++ function objects• Iterators in STL/C++ share interface by convention/templates¾ Implementation varies while interface stays the samez Second view: share code, factor code into parent class¾ Code in parent class shared by subclasses¾ Subclasses can override inherited method• Can subclasses override and call?z Polymorphism/late(runtime) binding (compare: static)¾ Actual function called determined when program runs, not when program is compiledSoftware Design3.4Inheritance guidelines in C++z Inherit from Abstract Base Classes (ABC)¾ one pure virtual function needed (=0)• Subclasses must implement, or they’re abstract too¾ must have virtual destructor implemented• can have pure virtual destructor with an implementation, but this is special case, not normally needed [force ABC]z Avoid protected data, but sometimes this isn’t possible¾ data is private, subclasses have it, can’t access it¾ keep protected data to a minimumz Single inheritance, assume most functions are virtual¾ multiple inheritance ok when using ABC, problem with data in super classes¾ virtual: some overhead, but open/closed principle intactSoftware Design3.5Inheritance Heuristicsz A base/parent class is an interface¾ Subclasses implement the interface• Behavior changes in subclasses, but there’s commonality¾ The base/parent class can supply some default behavior• Derived classes can use, override, both¾ The base/parent class can have state• Protected: inherited and directly accessible• Private: inherited but not accessible directly¾ Abstract base classes are a good thingz Push common behavior high up in an inheritance hierarchyz If the subclasses aren’t used polymorphically (e.g., through a pointer to the base class) then the inheritance hierarchy is probably flawedSoftware Design3.6Inheritance Heuristics in C++z One pure virtual (aka abstract) function makes a class abstract¾ Cannot be instantiated, but can be constructed (why?)¾ Default in C++ is non-virtual or monomorphic• Unreasonable emphasis on efficiency, sacrifices generality• If you think subclassing will occur, all methods are virtual¾ Must have virtual destructor, the base class destructor (and constructor) will be calledz We use public inheritance, models is-a relationship¾ Private inheritance means is-implemented-in-terms-of• Implementation technique, not design technique• Derived class methods call base-class methods, but no “usable-as-a” via polymorphism• Access to protected methods, and can redefine virtual funcsSoftware Design3.7Inheritance and Layering/Aggregationz Layering (or aggregation) means “uses via instance variable”¾ Use layering/attributes if differences aren’t behavioral¾ Use inheritance when differences are behavioralz Consider Student class: name, age, gender, sleeping habits¾ Which are attributes, which might be virtual methodsz Lots of classes can lead to lots of problems¾ It’s hard to manage lots of classes in your head¾ Tools help, use speedbar in emacs, other class browsers in IDEs or in comments (e.g., javadoc)z Inheritance hierarchies cannot be too deep (understandable?)Software Design3.8Inheritance guidelines (from Riel)z Beware derived classes with only one instance/object¾ For the CarMaker class is GeneralMotors a subclass or an object?z Beware derived classes that override behavior with a no-op¾ Mammal class from which platypus derives, live-birth?z Too much subclassing? Base class House¾ Derived: ElectricallyCooledHouse, SolarHeatedHouse?z What to do with a list of fruit that must support apple-coring?¾ Fruit list is polymorphic (in theory), not everything corableSoftware Design3.9Spreadsheet: Model, View, Controllerz Model, View, Controller is MVC¾ Model stores and updates state of application• Example: calculator, what's the state of a GUI-calculator?¾ When model changes it notifies its views appropriately• Example: pressing a button on calculator, what happens?¾ The controller interprets commands, forwards them appropriately to model (usually not to view)• Example: code for calculator that reacts to button presses• Controller isn't always a separate class, often part of GUI-based view in M/VCSoftware Design3.10How do Model/View communicate?z Model has-a view (or more than one)¾ Can call view methods¾ Can pass itself or its fields/info to viewz View can call back on model passed (e.g., by model itself)¾ Model passes this, view accepts Model as parameter¾ Possible for controller/other class to pass modelz Controller contains both model and view (for example)¾ Constructs MV relationship¾ Possible for controller to be part of view (e.g., GUI)Software Design3.11Controller in MVCz Loop until game over, where is code for board display?while (true) {getMove(m,player); if (ttt.makeMove(m)){ if (ttt.gameOver()){ break; } player = (player == 'X' ? '0' : 'X'); }else {cout << “bad move “ << m << endl;}}Software Design3.12GUI controllerz Typically no loop, GUI events drive the system ¾ Wire events to event handlers (part of controller)¾ What about model/view game over coordination?connect(mouseClick, moveGenerator); // metacodevoid GUI::moveGenerator(MouseClick m){controller->process(moveFromMouse(m)); }void Controller::process(const TTTMove& m){if (! myModel->makeMove(m)){myView->showBadMove(m);}}Software Design3.13Designing classes in generalz Highly cohesive¾ Each class does one thing¾ Interface is minimally complete, avoid kitchen sink• What if client/user might want to hammer with an awl?z Loose coupling (and minimize coupling)¾ Classes depend on each other minimally¾