Duke CPS Why C++? l a better C ä type safe, e.g., I/O streams ä better support for ADTs, encapsulation l object-oriented programming ä add inheritance to encapsulation ä OO isn’t a silver bullet, but it helps in dealing with the complexity of software development l non OO programming ä sometimes non-class approach has merits l generic programming ä STL, the standard template library

Duke CPS Why inheritance? l standard shape example ä difficult to extend ä access to source ä change all functions ä what is state? l inheritance ä models is-a Liskov substitution principle ä cost? (who pays?) double Shape::area() const { switch (myKind) { case Shape::circle: return PI * myDim * myDim; case Shape::square: //... } class Shape { public: enum Kind {circle,square,...}; double area() const; void rotate(); private: Kind myKind; };

Duke CPS Inheritance l virtual functions provide runtime polymorphism ä must use pointers or references ä can extend base class without access to source l in C++ there are several kinds of inheritance ä public, private, virtual,... ä multiple inheritance l we’ll use single, public inheritance, trying to model “is-a” as much as possible l General goal: base classes are abstract, have one pure virtual function ä model an interface, not an implementation ä see roulette program for example, also map hierarchy

Duke CPS shapes: C++ features, what is “is-a”? class Shape { public: virtual double area() const = 0; }; class Square : public Shape { public: virtual double area() const {return mySide * mySide;} private: double mySide; }; class Rectangle : public Shape { public: virtual double area() const {return myWidth * myHeight;} };

Duke CPS Designing for change (extension) l How does inheritance help? l What about different table formats in hyperwag? ä is more than one layout possible? problems? if (headerStyle == normal)... else if (headerStyle == gaudy)... else if... l factory pattern helps here ä abstracts object creation, multiple look-and-feel ä can use factory for reading format, writing format,...

Duke CPS Factory Pattern l Consider classes for different look-and-feel styles NormalLayout wagNL;wagNL.makeHeader(); GaudyLayout wagGL;wagGL.makeHeader(); ä problems, how to choose styles, when to choose l Does inheritance help? (assume ABC, Layout) Layout * wag = new NormalLayout; Layout * wag = new GaudyLayout; wag->makeHeader(); ä is this better? are there problems? l Use a Layout Factory Layout * wag = factory->makeLayout(); wag->makeHeader(); ä dependencies exist, but in factory ä parameters to factory can set the look-and-feel returned

Duke CPS Design patterns l Add to vocabulary we use to communicate and think about design l Form part of a tool-kit we use when thinking about design l Help find solutions to design problems ä factory ä iterator see usewords.cc ä proxy ä also: adapter, singleton, observer, command ä also: model-view-controller, client-server, … ä GOF, gang-of-four, Gamma, Helms, Johnson, Vlissides ä we’re using Buschmann et al

Duke CPS usewords.cc l iterators ä internal, external ä creation/deletion ä use of inheritance and naming conventions l STL, Duke-classes ä what is a templated class/function? ä how are templates instantiated? ä drawbacks?

Duke CPS Data Structures, STL, Generic Programming l common container classes/data structures ä vector growable array ä map dictionary, (seach tree, hashtable) ä set union, intersection, membership l STL, Standard Template Library ä not just implemenations, but way of thinking ä little/no inheritance, lots of templates ä algorithms and functions generalized too l default often not-safe, implementations make heavy use of “new C++ features”

Duke CPS Thinking about thinking about hyperwag l issues in specification ä ambiguities ä missing pieces l classes: nouns; member functions: verbs ä what, not how ä responsibilities and collaboration among classes l other design/problem questions?

Duke CPS Designing Classes and Programs l Where do classes come from? ä nouns: brainstorm, cull, combine, divide ä attributes vs. classes, keep cohesion high l Things to watch out for ä kitchen sink classes: keep classes highly cohesive ä God classes: know about everything in the app ä classes with little behavior (only get/set), and few collaborators l CRC cards: classes, responsibilities, collaborators ä 3x5 card, class name at top, list responsibilities and collaborators

Duke CPS CRC card template Class name subclasses/superclasses responsibilitiescollaborators WagReader (abstract) parseStream getAppointment? iterators?... Appointment Stream WagMaker... Other classes in hyperwag?

Duke CPS working in groups/teams l work together/debate the design, don’t code until the design is understood by everyone ä what about initial hyperwag prototype? ä Doom: Design and implementation are iterative processes l what about controlling the source code, building the program? ä use RCS or CVS, start now (hopefully CVS soon, see web) ä build/make everyday, versions ok, a working program is a wonderful thing ä who’s in charge?

Duke CPS Brooks’ team (see chapter 3, Mythical Man Month) l surgeon, chief programmer l copilot l administrator l editor l program clerk l toolsmith l tester l language lawyer l secretaries (2) ä necessary? what about three-person teams

Duke CPS Other team formats l Everyone participates in design l Everyone codes l Someone has to be in charge l What about different views, levels of experience? l What can be done when someone doesn’t deliver? l How to live with the team (or not) l What’s the best way to get everyone to help? l Don’t leave anyone behind, don’t get left behind