CS427a: Object-Oriented Programming Design Patterns for Flexible and Reusable designReusability, Flexibility, and MaintainabilityThe Waterfall Software ProcessWhy a Pure Waterfall Process is Usually Not Practical The Spiral ProcessAdvantage of OO DesignAspect of ReusabilityMaking a Class Re-usableReducing Dependency Among ClassesAspect of FlexibilitySome Techniques to Achieve FlexibilityRoadmapWhat is a Design PatternUML/OMT NotationExample: Duck GameInitial DesignDesign Change: add fly()ProblemAnticipating ChangesHandling Varying BehaviorsDesignProgramming to implementation vs interface/supertypeImplementationExerciseThe Strategy PatternSlide 26Summary: Design PrinciplesExample: KitchenViewer InterfaceKitchenViewer ExampleSelecting Antique StyleKitchenViewer Using Standard InheritanceThe Abstract Factory IdeaAbstract Factory Design Pattern Applied to KitchenViewerAbstract Factory Design PatternConcrete and Abstract LayersAbstract Factory Application Sequence DiagramPotential use of this Design Pattern?CS427a: Object-Oriented Programming Design Patterns for Flexible and Reusable designMichael J. Fischer(from slides by Y. Richard Yang)Lecture 20November 16, 2010Reusability, Flexibility, and Maintainability•One thing constant in software development is CHANGE•For software that is used over a period of years, the cost of keeping it current in the face of changing needs often exceeds the cost of originally developing it.•A key need in software design is the ability for maintenance and modification to keep abreast of changes.The Waterfall Software ProcesstimeRequirementsAnalysisDesignMilestone(s)Phases (activities)ImplementationTestingMaintenanceRelease product XTwo phases may occur at the same time for a short periodWhy a Pure Waterfall Process is Usually Not Practical Don’t know up front everything wanted and needed–Usually hard to visualize every detail in advance To gain confidence in an estimate, we need to design and actually implement parts, especially the riskiest ones, this may probably lead to modify requirements as a resultWe often need to execute intermediate builds–Stakeholders need to gain confidence–Designers and developers need confirmation they're building what’s needed and wantedTeam members can't be idle while the requirements are being completedThe Spiral Processtime 1 RequirementsanalysisDesignCodingTesting1Iteration # 11 2 2 23 3 3 Product released XIntermediate version* completed X*typically a prototypeM I L E S T O N E S 2 3 2 3 1Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.Advantage of OO DesignOO systems exhibit recurring structures that promote–Abstraction–Modularity–Flexibility–Extensibility–EleganceAspect of Reusability• Classes – in source code form–Thus, we write generic code whenever possible• Assemblies of related classes A toolkittoolkit is a library of reusable classes designed to provide useful, general-purpose functionality.•E.g., C++ standard library, BoostAn application framework application framework is a specific set of classes that cooperate closely with each other and together embody a reusable design for a category of problems.•E.g., Java APIs (Applet , Thread, etc), gtkmm•Design patternMaking a Class Re-usableDefine a useful abstraction–attain broad applicabilityReduce dependencies on other classes…Reducing Dependency Among ClassesStudentReplace …Coursewith …Student CourseEnrollmentAspect of Flexibility•Making small variation to existing functionality•Adding new kinds of functionality•Changing functionalitySome Techniques to Achieve FlexibilityFlexibility Aspect: ability to … Some techniques… create objects in variable configurations determined at runtime“Creational” design patterns… create variable trees of objects or other structures at runtime “Structural” design patterns… change, recombine, or otherwise capture the mutual behavior of a set of objects“Behavioral” design patterns… create and store a possibly complex object of a class.Component… configure objects of predefined complex classes – or sets of classes – so as to interact in many waysComponentRoadmap•We will focus on flexibility and reusability–It is important to remember that real systems also need to consider efficiency and robustness•We will start with design patterns, and then look into the design of some OO libraries/toolkit/framework•We will learn by examples:–Example is not another way to teach, it is the only way to teach. -- Albert EinsteinWhat is a Design Pattern•Abstracts a recurring design structure•Comprises class and/or objectdependenciesstructuresinteractionsconventions•Distills design experience•Names & specifies the design structure explicitly•Language- & implementation-independent•A “micro-architecture”14UML/OMT NotationExample: Duck Game•A startup produces a duck-pond simulation game•The game shows a large variety of duck species swimming and making quacking soundsInitial DesignMillardDuckdisplay() { looks like a mallard}RedheadDuckdisplay() { looks like a redhat}Other types of ducksDuckquack()swim()display() = 0// Other duck-like methodDesign Change: add fly()Duckquack()swim()display() = 0fly()// Other duck-like methodMillardDuckdisplay() { looks like a mallard}RedheadDuckdisplay() { looks like a redhat}Other types of ducksProblem•Generalization may lead tounintended behaviors: a rubber duck is flying and quacksDuckquack()swim()display() = 0// Other duck-like methodRubberDuckdisplay() {looks like a rubber duck}quack() { // sqeak }fly() { // cannot fly }MillardDuckdisplay() { looks like a mallard}Anticipating Changes•Identify the aspects of your application that may vary–What may change?•Anticipate that –new types of ducks may appear and –behaviors (quack, swimming, and flying) may change, even change at run time (swirl flying, circular flying, …)Handling Varying Behaviors•Solution: take what varies and “encapsulate” it–Since fly() and quack() vary across ducks, separate these behaviors from the Duck class and create a new set of classes to represent each behaviorsuper class of all ducksVarying and run-time changeable behaviorsDesign•Each duck object has a fly behaviorFlyWithWingsfly() { //}FlyNoWayfly() { // cannot fly}<<interface>>FlyBehaviorfly()Programming to