© Kenneth M. Anderson, 2011PRINCIPLES OF DESIGN PATTERNSCSCI 4448/5448: OBJECT-ORIENTED ANALYSIS & DESIGNLECTURE 22 — 03/31/20111Wednesday, March 30, 2011© Kenneth M. Anderson, 2011Goals of the LectureCover the material in Chapters 14 of our textbookPrinciples of Design Patterns2Wednesday, March 30, 2011© Kenneth M. Anderson, 2011Principles of Design Patterns (I)One benefit of studying design patterns is that they are based on good object-oriented principleslearning the principles increases the chance that you will apply them to your own designsWe’ve encountered several principles this semester alreadyCode to an interfaceEncapsulate What VariesOnly One Reason to ChangeClasses are about behaviorPrefer delegation over inheritanceDependency Inversion Principle3Wednesday, March 30, 2011© Kenneth M. Anderson, 2011Principles of Design Patterns (II)Code to an interfaceIf you have a choice between coding to an interface or an abstract base class as opposed to an implementation or subclass, choose the formerLet polymorphism be your friendPizza store exampleTwo a b s t r a c t b a s e c l a s s e s : Pizza and Pizza StoreThere were a LOT of classes underneath, all hidden4Wednesday, March 30, 2011© Kenneth M. Anderson, 2011Principles of Design Patterns (III)Encapsulate What VariesIdentify the ways in which your software will changeHide the details of what can change behind the public interface of a classCombine with previous principle for powerful resultsNeed to cover a new region? New PizzaStore subclassNeed a new type of pizza? New Pizza subclass5Wednesday, March 30, 2011© Kenneth M. Anderson, 2011Principles of Design Patterns (IV)Only One Reason to ChangeEach class should have only one design-related reason that can cause it to changeThat reason should relate to the details that class encapsulates/hides from other classesThe FeatureImpl class discussed during last lecture has only one reason to changea new CAD system requires new methods in order to fully access its features6Wednesday, March 30, 2011© Kenneth M. Anderson, 2011Principles of Design Patterns (V)Classes are about behaviorEmphasize the behavior of classes over the data of classesDo not subclass for data-related reasons; It’s too easy in such situations to violate the contract associated with the behaviors of the superclassThink back to our Square IS-A/HAS-A Rectangle exampleRelated: Prefer Delegation over Inheritance; to solve the Square/Rectangle problem, we resorted to delegation; it provides a LOT more flexibility, since delegation relationships can change at run-time7Wednesday, March 30, 2011© Kenneth M. Anderson, 2011Principles of Design Patterns (VI)Dependency Inversion Principle“Depend upon abstractions. Do not depend upon concrete classes.”Normally “high-level” classes depend on “low-level” classes;Instead, they BOTH should depend on an abstract interfaceWe saw this when discussing the Factor y Method back in lecture 98Wednesday, March 30, 2011Dependency Inversion Principle: Pictorially 9Level 1Level 2ClientConcreteServiceHere we have a client class in an “upper” level of our design depending on a concrete class that is “lower” in the designWednesday, March 30, 2011Dependency Inversion Principle: Pictorially 10Level 1Level 2ClientConcreteServiceServiceInterfaceInstead, create an interface that lives in the upper level that hides the concrete classes in the lower level; “code to an interface”Wednesday, March 30, 2011Dependency Inversion Principle: Pictorially 11Level 1Level 2ClientConcreteServiceServiceInterfaceNow, instead of Client depending on a Concrete service, they BOTH depend on an abstract interface defined in the upper levelWednesday, March 30, 2011© Kenneth M. Anderson, 2011Principles of Design Patterns (VII)Let’s learn about a few more principlesOpen-Closed PrincipleDon’t Repeat YourselfSingle Responsibility PrincipleLiskov Substitution PrincipleSome of these just reinforce what we’ve seen beforeThis is a GOOD thing, we need the repetition…12Wednesday, March 30, 2011© Kenneth M. Anderson, 2011Open-Closed Principle (I)Classes should be open for extension and closed for modificationBasic Idea:Prevent, or heavily discourage, changes to the behavior of existing classesespecially classes that exist near the root of an inheritance hierarchyYo u ’ v e g o t a l o t o f c o d e t h a t d e p e n d s o n t h i s b e h a v i o rIt should not be changed lightly13Wednesday, March 30, 2011© Kenneth M. Anderson, 2011Open-Closed Principle (II)If a change is required, one approach would be to create a subclass and allow it to extend/override the original behaviorThis means you must carefully design what methods are made public and protected in these classesprivate methods cannot be extended14Wednesday, March 30, 2011© Kenneth M. Anderson, 2011Is this just about Inheritance? (I)Inheritance is certainly the easiest way to apply this principlebut its not the only wayThink about the delegate pattern we saw in iOSWe can customize a class’s behavior significantly by having it assume the existence of a delegateIf the delegate implements a delegate method, then call it, otherwise invoke default behavior15Wednesday, March 30, 2011© Kenneth M. Anderson, 2011Is this just about Inheritance? (II)In looking at Design Patterns, we see that composition and delegation offer more flexibility in extending the behavior of a systemInheritance still plays a role but we will try to rely on delegation and composition first16Wednesday, March 30, 2011© Kenneth M. Anderson, 2011Open-Closed Principle (III)Returning to the open-closed principle, the key point is to get you to be reluctant to change working codelook for opportunities to extend, compose and/or delegate your way to achieve what you need first17Wednesday, March 30, 2011© Kenneth M. Anderson, 2011Don’t Repeat Yourself (I)Avoid duplicate code by abstracting out things that are common and placing those things in a single locationBasic IdeaDuplication is Bad!… at all stages of software engineering: analysis, design, implement, and test18Wednesday, March 30, 2011© Kenneth M. Anderson, 2011Don’t Repeat Yourself (II)We want to avoid duplication in our requirements & use casesWe want to avoid duplication of responsibilities in our codeWe want to avoid duplication of test coverage in our testsWhy?Incremental errors can creep into a system when one copy is changed but the others are notIsolation of Change