DOC PREVIEW
CU-Boulder CSCI 5828 - Good-Enough Design & Version Control

This preview shows page 1-2-3-4-5-35-36-37-38-39-70-71-72-73-74 out of 74 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 74 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

© University of Colorado, 2010Good-Enough Design & Version ControlKenneth M. AndersonUniversity of Colorado, BoulderCSCI 5828 — Lecture 11 — 02/16/20101GoalsReview material from Chapter 5 of Pilone & MilesSoftware Design: Need for Good OO A&D principlesSRP: Single Responsibility PrincipleDRY: Don’t Repeat Yourself PrincipleReview material from Chapter 6 of Pilone & MilesVersion Control & Configuration ManagementWorking “Without a Net”Repository ManagementInit, Add, Branch, Merge2iSwoon in TroubleThe previous chapter presents a design for associating dates and events that was causing problemsDate objects maintain a list of its planned eventsAn Event object is a “dumb data holder” storing only a nameIt has no logic of its ownDate objects provide methods that internally add events to a planned date; The Date object contains information about what events are allowed on a particular dateThe UML diagram is shown on the next slide34+ seeMovie() : void+ goToRestaurant() : void+ orderFlowers() : void+ goOnDate() : boolean- validateEvent(event: Event) : booleanDate- validateEvent(event: Event) : booleanFirstDate- validateEvent(event: Event) : booleanSecondDate- validateEvent(event: Event) : booleanThirdDate+ getName(): StringEvent+ getName() : String- name : String = "SeeMovie"SeeMovieEvent+ getName() : String- name : String = "GoToRestaurant"GoToRestaurantEvent+ getName() : String- name : String = "OrderFlowers"OrderFlowersEventevents*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 DatesUML Diagram5validateEvent(...):System:FirstDate:GoToRestaurantEvent«create»goToRestaurant(...)«create»validateEvent(...)getName()seeMovie(...)«create»:SeeMovieEventgetName()return Truereturn TruegoOnDate()UML Sequence Diagram6Bad Design (I)This design has a lot of problemsThe Event class is completely uselessWhy not have Date store an array of strings?Date’s API is pretty badEvent 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)Bad Design (II)But those are relatively minor issuesThe main reason why this design is bad is that its inflexible with respect to the types of changes that occur regularly for this application domainIt can’t easily handle the addition of a new type of EventIt can’t easily handle changing the name of an existing EventIt can’t easily handle the changing of what events are valid for what dates7Good DesignA primary goal in OO A&D is producing a design that makeslikely changes, straightforwardtypically by adding a new subclass of an existing classor by adding an object that implements a known interfaceno need to recompile the system or even it bring it downYou can’t anticipate arbitrary changes and there is no reason to invest time/$$ into planning for unlikely changesSo use good OO A&D principles to handle likely changes8Single Responsibility Principle (SRP) (I)The Date class has multiple responsibilitiestracking the events planned for a datetracking the events allowed for a dateIt has multiple reasons to changeThe single responsibility principle saysEvery object in your system should have a single responsibility and all the object’s services should be focused on carrying out that single responsibilityThis is also known as “having high cohesion”9SRP (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”10SRP (III)The existing iSwoon design is bad because each time we add a new eventWe need to add a new Event subclassAdd a new method to DateUpdate 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 more11Textual Analysis (I)One way of identifying high cohesion in a system is to do the followingFor each class CFor each method MWrite “The C Ms itself”ExamplesThe Automobile drives itselfThe Automobile washes itselfThe Automobile starts itself12Textual Analysis (II)Sometimes you need to include parameters in the sentenceThe CarWash washes the Automobile itself If any of these sentences doesn’t make sense then investigate furtherYou may have discovered a service that belongs to a different responsibility of the system and should be moved to a different classThis may require first creating a new class before performing the move13Textual Analysis (III)Textual analysis is a good heuristicWhile its useful for spot checking a design, its not perfectBut the underlying principle is soundEach class in your design should “pull its weight”have a single responsibility with a nice balance of both data AND behavior for handling that responsibility14Other ProblemsThe iSwoon design also has problems with duplication of information (indeed duplication can often lead to classes with “low cohesion” that violate SRPThe duplication in iSwoon is related to Event TypesThe names of event types appear inEvent subclass namesThe name attribute inside of each event subclassThe method names in DateIn addition, duplication occurs with validateEvent() in each of the Date subclasses15Don’t Repeat Yourself (I)The DRY principleAvoid duplicate code by abstracting out things that are common and placing those things in a single locationBasic IdeaDuplication is Bad!At all levels of software engineering: Analysis, Design, Code, and Test16DRY (II)We want to avoid duplication in our requirements, use cases, feature lists, etc.We 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 Requests: We want to go to ONE place when responding


View Full Document

CU-Boulder CSCI 5828 - Good-Enough Design & Version Control

Documents in this Course
Drupal

Drupal

31 pages

Deadlock

Deadlock

23 pages

Deadlock

Deadlock

23 pages

Deadlock

Deadlock

22 pages

Load more
Download Good-Enough Design & Version Control
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Good-Enough Design & Version Control and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Good-Enough Design & Version Control 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?