Originality is Overrated: OO Design Principles&Iterating And TestingKenneth M. AndersonUniversity of Colorado, BoulderCSCI 4448/5448 — Lecture 12 — 10/01/2009© University of Colorado, 20091Lecture Goals: Part One• Review material from Chapter 8 of the OO A&D textbook• Object-Oriented Design Principles• Open-Closed Principle• Don’t Repeat Yourself• Single Responsibility Principle• Liskov Substitution Principle• Aggregation and Composition, Revisited• Discuss the examples in Chapter 8• Emphasize the OO concepts and techniques encountered in Chapter 82Lecture Goals: Part Two• Review material from Chapter 9 of the OO A&D textbook• Iteration is fundamental• Feature driven development• Use case driven development• Testing is fundamental• Test driven development• Proving yourself to the customer• Programming by Contract• Defensive Programming• Discuss the examples in Chapter 9• Emphasize the OO concepts and techniques encountered in Chapter 93Originality is Overrated• Corollary: “Only Steal from the Best” — various sources• OO A&D has been performed in various forms and in various contexts for nearly 40 years• Over that time, designers have developed a set of principles that ease the task of creating OO designs• If you apply these principles in your own code, you will be “stealing” from the best that the OO A&D community has to offer• The same is true of Design Patterns4OO Principles: What We’ve Seen So Far• We’ve seen the following principles in action over the past eight lectures•Classes are about behavior• Emphasize the behavior of classes over the data of classes• Don’t subclass for data-related reasons• Encapsulate what varies• Provides info. hiding, limits impact of change, increases cohesion• One reason to change• Limits impact of change, increases cohesion• Code to an Interface• Promotes flexible AND extensible code• Code applies across broad set of classes, subclasses can be added in a straightforward fashion (including at run-time)5New Principles•Open-Closed Principle (OCP)• Classes should be open for extension and closed for modification• Don’t Repeat Yourself (DRY)• Avoid duplicate code by abstracting out things that are common and placing those things in a single location• Single Responsibility Principle (SRP)• Every object in your system should have a single responsibility, and all the object’s services should be focused on carrying it out• Liskov Substitution Principle (LSP)• Subtypes must be substitutable for their base types6Open-Closed Principle• Classes should be open for extension and closed for modification• Basic Idea:• Prevent, or heavily discourage, changes to the behavior of existing classes• especially classes that exist near the root of an inheritance hierarchy• If a change is required, create a subclass and allow it to extend/override the original behavior• This means you must carefully design what methods are made public and protected in these classes; private methods cannot be extended• Why is this important?• Limits impact on code that follows “Code to an Interface” principle• If you change the behavior of an existing class, a lot of client code may need to be updated7Example• We’ve seen one example of the Open-Closed Principle in action• InstrumentSpec.matches() being extended by GuitarSpec and MandolinSpecgetBuilder(): BuildergetModel(): StringgetType(): TypegetBackWood(): WoodgetTopWood(): Woodmatches(InstrumentSpec): booleanmodel: StringInstrumentSpecgetStyle(): Stylematches(InstrumentSpec): booleanMandolinSpecgetNumStrings(): intmatches(InstrumentSpec): booleannumStrings: intGuitarSpec8Is this just about Inheritance?• Inheritance is certainly the easiest way to apply this principle• but its not the only way• In looking at Design Patterns, we’ll see that composition and delegation offer more flexibility in extending the behavior of a system• Inheritance still plays a role but its more background than foreground•The key point of the OCP is to get you to be reluctant to change working code, look for opportunities to extend, compose and/or delegate your way to achieve what you need first9Don’t Repeat Yourself• Avoid duplicate code by abstracting out things that are common and placing those things in a single location• Basic Idea• Duplication is Bad!• At all levels of software engineering: Analysis, Design, Code, and Test• We want to avoid duplication in our requirements, use cases, feature lists, etc.• We want to avoid duplication of responsibilities in our code• We want to avoid duplication of test coverage in our tests• Why?• Incremental errors can creep into a system when one copy is changed but the others are not• Isolation of Change Requests: We want to go to ONE place when responding to a change request10recognize(bark: string)BarkRecognizerpressButton()Remoteopen()close()isOpen(): booleanopen: booleanDogDoordoordoorDogDoorSimulator• Duplication of Code: Closing the Door in Chapter 2• We had the responsibility for closing the door automatically in our “dog door” example originally living in the RemoteControl Class.• When we added a BarkRecognizer Class to the system, it opened the door automatically but failed to close the door• We could have placed a copy of the code to automatically close the door in BarkRecognizer but that would have violated the DRY principle• Instead, we moved the responsibility to the shared Door classExample (I)11Example (II)• DRY is really about ONE requirement in ONE place• We want each responsibility of the system to live in a single, sensible place• New Requirements for the Dog Door System: Beware of Duplicates• The dog door should alert the owner when something inside the house gets too close to the dog door• The dog door will open only during certain hours of the day• The dog door will be integrated into the house’s alarm system to make sure it doesn’t activate when the dog door is open• The dog door should make a noise if the door cannot open because of a blockage outside• The dog door will track how many times the dog uses the door• When the door closes, the house alarm will re-arm if it was active before the door opened12Example (III)• New Requirements for the Dog Door System: Beware of Duplicates• The dog door should alert the owner when something inside the house gets too close to the dog door• The