Class Note for CMPSCI 220 at UMass(6)
Class Note for CMPSCI 220 at UMass(6)
Popular in Course
Popular in Department
This 8 page Class Notes was uploaded by an elite notetaker on Friday February 6, 2015. The Class Notes belongs to a course at University of Massachusetts taught by a professor in Fall. Since its upload, it has received 15 views.
Reviews for Class Note for CMPSCI 220 at UMass(6)
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 02/06/15
Goals Last Week and Today CMPSCI 220 291A Programming Methodology I Increase sense ofincremental nature of Spring 2009 Iefactoring I Week ago Conditional Expressions REF 9 and Method Calls REF 10 26 Refactoring Generalization and Big 39 LaSt dme comPOSing methOds REF 6gt Moving features around REF 7 Data REF 8 Today Dealing with Generalization REF 12 and Big Refactorings REF 13 Build your catalog of familiar refactorings UNIVERsmr 0F MASSACHUSETES AMHERST Depantmentofcomputer Science I 39739 7 7 UNIVERSITY OF MASSACHUSETTS AMHERST Department ofCompmer Science Refactorings for Generalization Refactorings for Generalization I Most involve moving methods and elds I Method generalization separating common around in inheritance hierarchy ou jne from distinct details 39 Pun UP MethOCL Pun UP Field I Form Template Method lecture 20 I Push Down Method Push Down Field I Pull Up Constructor Body I Replace Constructor with Factory Method 20 I Inheritance vs delegation I Replace inheritance With delegation I Replace delegation with inheritance I Other involve changing hierarchy I Extract Subclass Extract Superclass I Extract Interface Collapse Hierarchy UNIVERSITY OF MAssXCHUSEIEAMHERST Department of Computer science 3 V UNIVERSITY OF MASSACHUSHE AMHERST Department of Computer science Refactoring Pull Up Field Mechanics Confirm all uses of elds are the same I Problem Two subclasses have the same eld I I Based on how used names may not be the same I If EIdS d0 nOt all haVe same name I Possibly result of independent development or 39 Re m ne to we deSifed in SUPefCIZSS previous refactoring I Compile and test I Refactoring Generalize by moving eld to l Create new eld in superclass superclass I Delete subclass elds I Removes duplicate data declaration I Compile and test I Enables moving behavior to superclass I Consider Self Encapsulate Field on new eld I Or Use Eclipse Fquot 7 UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Science UNIVERSITY or MASSACHUSETTS AMHERST Department of Computer Science Example Pull Up Field Example Pull Up Field 2 Customer Customer lastBiIIDate RegularCustomer PreferredCustomer RegularCustomer PreferredCustomer lastBiIIDate lastBiIIDate UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Science 7 I UNIVERSITY OF MASSACHUSETTS AMHERST Department of Compmer Science Refactoring Pull Up Method Mechanics I Problem Two subclasses have methods with I Con rm methods are identical identical results I If not use algorithm substitution on one I Possibly identical bodies from cut and paste If methods have different signatures I Must confirm differences don t affect results I Change to Signature desired in supefclass I Refactoring Generalize by moving method to I Create new method in superdass superdass I Copy body from one method I Removes duplication and maintenance headache I May need to pull up other abstract methods I Often follows other refactorings I May need to pull up fields I Eg changing parameter lists I Adjust and compile UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Science UNIVERSITY OF MASSACHUSE I EAMHERST Department of Computer science Mechanics cont Example Pull Up Method I Delete one subclass method Customer I Compile and test I Keep deleting subclass methods until only the superclass method remains I Check callers to see if required type can be M W Changed to superdass createBi createBi I Or Use Eclipse UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Science Example Pull Up Method 2 Refactoring Push Down Method I Problem Behavior in superclass is only Customer createBmo relevant to some of its subclasses l Opposite of Pull Up Method l Often accompanies Extract Subclass RegularCustomer PreferredCustomer I Refactoring Move method to relevant subclasses UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Science I UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Scienee Mechanics Example Push Down Method I Declare a method in all subclasses I And copy body into each subclass I May need to declare fields protected which will later be createBlllo pushed down I Remove the method from the superclass Some adjustments may be required RegularCustomer PreferredCustomer I Compile and test I Remove the method from each subclass that doesn t need it I Compile and test 7 I Or Use Eclipse H UNIVERSITY OF MASSACHUSETTS AMHERST Department Of Computer Science 5 UNIVERSITY OF MASSACHUSHTS AMHERST Department Of Compmer Science Example Push Down Method 2 Refactoring Push Down Field I Problem Field in superclass is only relevant to Customer some of its subclasses I Opposite of Pull Up Field I Refactoring Move eld to relevant subclasses Regula rCustomer PreferredCustomer createBi UNIVERSITYle MASSAEHTISETFS AMHERST Department of Computer Science I I UNIVERSITYioF MAsgAc snTs AMHERST Department of Computer Science Mechanics Example Push Down Field I Declare the eld in all subclasses Customer I Remove the eld from the superclass IasthDate I Compile and test 39 I Remove the eld from all subclasses that don t need it RegularCustomer PreferredCustomer I Compile and test I Or Use Eclipse UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Science E I UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Science Example Push Down Field 2 Refactoring Extract Interface I Problem Several clients use same subset of a class s interface I Problem Two classes have part of their interfaces in common Customer RegularCustomer PreferredCustomer I Clients need to work with any class that supports lastBiIIDate common set of behaviors I Refactoring Extract the subset to an interface I Can lead to smelly duplicate code I Use Extract Class and delegate UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Science 2 UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Science Mechanics Example Extract Interface I Create an empty interface public class EmpioyeeI I Declare the common operations in the public Strng getName 0 raturn ame interface getRate rat ean hasSpecla Declare the relevant classes as E hasSpeclalSkJ implementing the interface 39 fi f ra39te 39 39 39 39 39 39 39 39 I Adust client type declarations to use the Private b 1ean ihasspecmlskllli private String iname interface private String iaddress I I Or Use Eclipse 7 UNIVERSITY MASSAmSET39rS AMHERST Department of Computer Science 7 UNIVERSITY MAEAJISEITS AMHERST Department of Computer Science Example Extract Interface 2 Example Extract Interface 3 rface Blllabl ate EsSpecialSki public class Timesheeti public double chargeEmployee empint daysH int baseemp getRate days ifemphasspec1alsklll public class Employee 39 return base105 contents of thls ole s same gs before else return base public class Timesheeti public double chargell Tjint daysH int baseempgetRatedays ifemphasSpeclalSklll return basel 05 else return base i UNIVERsmr 0F MASSACHUSETES AMHERST Department of Computer Science UNIVERSITY OF MASSACHUSETFS AMHERST Department of Compmer Science Big Refactorings Big Refactorings I So far have considered refactoring moves I Tease Apart Inheritance I Small welledefined steps With specific purposes I Untangle inheritance hierarchy I What does the larger game look likegt I Convert Procedural Design to Objects I What purpose do the refactoring moves servegt I From 00 language to 00 design I Larger game Big Refactorings I Separate Domain from Presentation I Less detailed mechanics more context specific I Target is MVC pattern I Take much longer to complete months vs hours I Extract Hierarchy I But result in clear fully understood designs From overly complex Class to subclasses Umvtnsm 0E MaximumEmma Department of Computer science Umvtnsm 0E MASSACHUSHE AMHERST Department of Computer Science Big Refactoring Tease Apart Inheritance Mechanics I Problem Inheritance hierarchy doing two I Identify different jobs being done make table jobs at once I Decide which is most important which to move I Possibly due to subclass creep l Extract Class at common superclass for I Duplicate code maintenance headaches sub Sldlary 10b add Instance vanable for It I Refactoring Create two hierarchies and use I Subclasses matchmg those 1n or1g1nalh1erarchy I Instance variable points to an instance I Move Meth0ds into extracted subclasses I Eliminate empty subclasses until all gone I Consider Pull Up Method Pull Up Field delegation to invoke one from the other UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Science UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Science Example Example Tease Apart Inheritance Tease Apart Inheritance Table of Jobs Active Deal Deal Active Deal Passive Deal Tabular Deal Tabular Active Dea Tabular Passive Deal Grid to identifyjobs being done Deals more important than presentation style Subclasses turn single deals into tables of deals Se extract presentation Style into itS own hierarchy More kinds of deals more kinds of tables UilvEnsmr or MASSACHUSETTS AMHERSI Department of om pubar Science iUIhVERSITY or MASSACHUSFI39fSI AMHERST Department olTCompmver Sciense Example Example Tease Apart Inheritance 2 Tease Apart Inheritance 3 Presentation Style Presentation Style Single Active Active Deal Passive Deal Active Deal Passive Deal presentation Style A A Single Passive Presentation Style Tabular Active Deal I ITabular Passive Deal I Tabular Active Deal I I Tabular Passive Deal Tabular Active o Create subclasses for each class in Presentation Style Extract Class to create Presentatlon Style class original hierarchy Use Move Method and Move Field to Tabu39ar PaSSive I presentationrelated components Presentation Style iumvznsm OWMHERST Department of Computer science 7 imuvznsmiormmumn Department or Computer science Example Example Tease Apart Inheritance 4 Tease Apart Inheritance 5 Presentation Style Presentation Style smgle Acme Active Deal Presentation Style Tabular Single Presentation Style Presentation Style Active Deal Single Passive Presentation Style Should wind up with no code in Tabular X subclasses Tabular Active So remove them Presentation Style Simplify each hierarchy separately Eg can eliminate activepassive distinction in presentation styles Tabular Passive Presentation Style UNIVERSITY or MASSACHUSETTS AMHERST Department of Computer Science UNIVERSITY or MASSACHUSETTS AMHERST Department of Computer Science Example Big Refactoring Tease Apart Inheritance 6 Extract Hierarchy I Problem A class doing too much work I Partly through many conditional statements Active Deal I Refactoring Create a hierarchy of classes I Where each subclass represents a special case I May take weeks or months to untangle Can even replace single and tabular distinction with a few variables So eliminate the Presentation Style subclasses UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Science I UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Salemn Mechanics If Variations Unclear Mechanics If Variations Unclear l Identify a variation I One at a time copy methods that contain conditional I If subject to change Extract Class logic to SUbClaSS I Simplify based on subclass properties I create a subCIQSS for the SPeClal case I lfnecessary use Extract Method to separate conditional from I Use Replace Constructor With Factory Method unconditional parts of method on the original Class I Continue isolating special cases until superclass is I Make factory method return instance of new abStMCt subclass where appropriate I Delete bodies ofmethods that are overridden in all subclasses I Make their declarations abstract UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Science V UNIVERSITY OF MASSACHUSETTS AMHERST Department of Computer Science Mechanics If Variations Clear Example Extract Hierarchy I Create a subclass for each variation I Use Replace Constructor With Factory Method to return appropriate subclass for each variation I Apply Replace Conditional with Polymorphism L ts f ft H f o o 0 con IIona ogIc or to methods that have conditional logic different billing circumstances I If necessary use Extract Method to separate conditional from unconditional parts of methods UNIVERSIWillFiIASSACHLISEWS AMHERST Department of Computer Science 1 UNIVERSITY MASSACHUSHTS AMHERST Department of Computer Science Example Extract Hierarchy 2 Business Residential Disability Billing Scheme Billing Scheme Billing Scheme Separate out code that applies to one circumstance Replace Constructor with Factory Method Use Extract Method and Decompose Conditional UilvEnsmr or MAssAcHusmEs AMHERSI Department or Com puhar Science
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'