Good Enough Design Version Control Kenneth M Anderson University of Colorado Boulder CSCI 5828 Lecture 11 02 16 2010 University of Colorado 2010 1 Goals Review material from Chapter 5 of Pilone Miles Software Design Need for Good OO A D principles SRP Single Responsibility Principle DRY Don t Repeat Yourself Principle Review material from Chapter 6 of Pilone Miles Version Control Configuration Management Working Without a Net Repository Management Init Add Branch Merge 2 iSwoon in Trouble The previous chapter presents a design for associating dates and events that was causing problems Date objects maintain a list of its planned events An Event object is a dumb data holder storing only a name It has no logic of its own Date objects provide methods that internally add events to a planned date The Date object contains information about what events are allowed on a particular date The UML diagram is shown on the next slide 3 UML Diagram Date seeMovie void goToRestaurant void orderFlowers void goOnDate boolean validateEvent event Event boolean 4 FirstDate validateEvent event Event boolean SecondDate validateEvent event Event boolean events SeeMovieEvent name String SeeMovie getName String ThirdDate validateEvent event Event boolean Event getName String OrderFlowersEvent name String OrderFlowers getName String GoToRestaurantEvent name String GoToRestaurant getName String UML Primer Each rectangle represents a class that can have attributes and methods A symbols refers to public visibility indicates private visibility The means zero or more The large triangle indicates inheritance The arrow head indicates one way navigation in the diagram above Dates know about Events while Events are blissfully unaware of Dates System create UML Sequence Diagram FirstDate goToRestaurant create 5 GoToRestaurantEvent validateEvent getName return True seeMovie create validateEvent getName return True goOnDate SeeMovieEvent Bad Design I This design has a lot of problems The Event class is completely useless Why not have Date store an array of strings Date s API is pretty bad Event creation methods are specified for all possible events that means that some dates have event creation methods for events that are not valid for them The Date class has a list of allowable events but doesn t show it on the diagram or it doesn t show the list of planned events either way it has two lists but only shows one 6 Bad Design II But those are relatively minor issues The main reason why this design is bad is that its inflexible with respect to the types of changes that occur regularly for this application domain It can t easily handle the addition of a new type of Event It can t easily handle changing the name of an existing Event It can t easily handle the changing of what events are valid for what dates 7 Good Design 8 A primary goal in OO A D is producing a design that makes likely changes straightforward typically by adding a new subclass of an existing class or by adding an object that implements a known interface no need to recompile the system or even it bring it down You can t anticipate arbitrary changes and there is no reason to invest time into planning for unlikely changes So use good OO A D principles to handle likely changes Single Responsibility Principle SRP I The Date class has multiple responsibilities tracking the events planned for a date tracking the events allowed for a date It has multiple reasons to change The single responsibility principle says Every object in your system should have a single responsibility and all the object s services should be focused on carrying out that single responsibility This is also known as having high cohesion 9 SRP II Granularity When we say responsibility we are not talking about low level concerns such as insert element e into array a at position i but design level concerns such as classify documents by keyword store client details manage itinerary of Jack and Jill s second date 10 SRP III The existing iSwoon design is bad because each time we add a new event We need to add a new Event subclass Add a new method to Date Update each of Date s subclasses cringe We need to migrate to a design in which the addition of a new type of event results in the addition of a new Event subclass and nothing more 11 Textual Analysis I One way of identifying high cohesion in a system is to do the following For each class C For each method M Write The C Ms itself Examples The Automobile drives itself The Automobile washes itself The Automobile starts itself 12 Textual Analysis II 13 Sometimes you need to include parameters in the sentence The CarWash washes the Automobile itself If any of these sentences doesn t make sense then investigate further You may have discovered a service that belongs to a different responsibility of the system and should be moved to a different class This may require first creating a new class before performing the move Textual Analysis III Textual analysis is a good heuristic While its useful for spot checking a design its not perfect But the underlying principle is sound Each class in your design should pull its weight have a single responsibility with a nice balance of both data AND behavior for handling that responsibility 14 Other Problems 15 The iSwoon design also has problems with duplication of information indeed duplication can often lead to classes with low cohesion that violate SRP The duplication in iSwoon is related to Event Types The names of event types appear in Event subclass names The name attribute inside of each event subclass The method names in Date In addition duplication occurs with validateEvent in each of the Date subclasses Don t Repeat Yourself I 16 The DRY principle 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 DRY II 17 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 request Example I 18 Duplication of Responsibility BarkRecognizer recognize bark Bark door DogDoor open boolean open close isOpen boolean getAllowedBark Bark setAllowedBark bark Bark
View Full Document
Unlocking...