Duke CPS CPS 108, Spring 1998 l Software Design and Implementation ä Object oriented programming and design ä good design helps do away with late night Teer-fests, but some late nights are inevitable ä your toolkit must include mastery of language/programming and design l What’s in the course? ä C++ and Java, team projects, mastery exams ä team projects can be more and less than the sum of their parts ä high-level abstractions, low-level details ä patterns, heuristics, and idioms

Duke CPS What’s ahead in programming and design l Language independent principles of design and programming ä design heuristics ä coupling, cohesion, small functions, small interfaces... ä design patterns ä factories, MVC aka observer/observable,... l Language specific: ä idioms ä smart pointers, vectors/arrays, overloaded operators... ä idiosyncracies, idiocies ä must define virtual constructor, comma operator...

Duke CPS Administrivia l check website and news regularly duke.cs.cps108 l Grading (see web pages) ä group projects: small, medium, large ä mastery programs (solo or semi-solo endeavors) ä readings and summaries ä tests l Evaluating team projects, role of TA, UTA, consultants ä face-to-face evaluation, early feedback l Compiling, tools, environments, Linux ä g released 11/14/98, read website

Duke CPS C++ idioms/general concepts l templates ä generic functions/container classes l inheritance ä design guidelines, benefits, drawbacks l low-level structures ä C-style arrays and strings compared to standard: STL, Tapestry l from C to C++ ä function pointers, function objects l build on generalities, transition to Java ä vectors, interfaces, stress general principles

Duke CPS Design Criteria Good design comes from experience, experience comes from bad design Fred Brooks (or Henry Petroski) l Design with goals: ä ease of use ä portability ä ease of re-use ä efficiency ä first to market ä ?????

Duke CPS How to code l Coding/Implementation goals: ä Make it run ä Make it right ä Make it fast ä Make it small l spiral design (or RAD or !waterfall or...) see DOOM specification design implementation

Duke CPS Design Heuristics: class and program rules-of-thumb (see text by Arthur Riel) l Coupling ä classes/modules are independent of each other ä goal: minimal, loose coupling ä do classes collaborate and/or communicate? l Cohesion ä classes/modules capture one abstraction/model ä keep things as simple as possible, but no simpler ä goal: strong cohesion (avoid kitchen sink) l The open/closed principle ä classes/programs: open to extensibility, closed to modification

Duke CPS Roulette: Classes, Responsibilities, Collaborators l Class diagram in UML ä unified modeling language (see class web page) ä system at a glance, relationships, heuristics, discussion l What does inheritance get us here? (see the non-OO version) ä l Why does a bet need a wheel? other issues? ä l What are responsibilities of bankroll? ä

Duke CPS Design patterns “... describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” Christopher Alexander, quoted in GOF l Example: iterator ä sequentially access elements of aggregate without exposing representation/implementation ä see DirEntry, List class, Map class ä heavily used in STL, with pointer like syntax l Factory ä virtual constructor, have system that doesn’t depend on how items are created

Duke CPS Pattern Essentials l Name ä good name provides a handle for the pattern, makes it easy to remember and use: vocabulary l Problem ä when the pattern is applicable, context, criteria to be met, design goals l Solution ä design, collaborations, responsibilities, and relationships of the classes/design elements l Consequences ä trade-offs, problems, results from applying pattern: help in evaluating applicability

Duke CPS hyperwag: Week-at-a-glance in hypertext l hypertext version of week-at-a-glance, see web page for complete details ä read file in wagalang (other languages too) # this is a fun week m9,12sleep th9,10cps 110 w9,10breakfast f9,10running mtwhf12,13lunch wf10,12cps 108 t10,12breakfast ä produce HTML table l classes? problems? issues? groups? ideas? l C++ questions, design questions

Duke CPS larger group/company issues see McCarthy, Dynamics of Software Development l establish a shared vision ä what is hyperwag? what can we add? ä harmonious sense of purpose l develop a creative environment ä the more ideas the better, ideas are infectious ä don’t flip the BOZO bit l scout the future ä what’s coming, what’s the next project ä what new technologies will affect this project