Class Note for CMPSCI 220 at UMass(5)
Class Note for CMPSCI 220 at UMass(5)
Popular in Course
Popular in Department
This 5 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 18 views.
Reviews for Class Note for CMPSCI 220 at UMass(5)
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
CMPSCI 220 291A Programming Methodology spring 2009 3 Design Patterns and Principles ner s Toolbox I 00 Basics Abstraction 7 grouping interfaces Encapsulation 7 hiding pnyate details Polymorphism 7 one piece of code many types Inheritance 7 grouping similar interfaces etc 00 Design Principles 00 Design Patterns n P attern Motiyating example Series of alternatives A design pn39neiple or three A pattern emerges Highly Skl led Programming I Proficient Iith Tools Methods The two are often interrelated Eng design methods and programming language Specifically 00 language features and design What Are Design Patterns Distillatioris of experience Best practices lnstantiations of design principles Basis for shared yoeahulary For desenhing designs Rationales for language usage guidelines E g gt Item 16 in Effective 1aya seeond Edition Targets for refaeton39ng The SimUDuck Application Buds Quack 0 SW m 0 mmsyx Homer dtzkrhke methods W Redhesdouek disp avU disp avu W s f 5 MRS Hiccks hke a maHard Hiccks hke a redhead A Standard 00 Design Now Let39s Add a New Feature Absttaction 7 how does it appeatp Want to add ying Encapsulation ewhete is it hetep Just a matter of using 00 techniques Polymorphism ewhete in this example Inhen39tance 7 how is it used hetep Making Ducks Fly RubberDucks Don39t Fly Duck Duck quaku quaku SWH V SWH H mo m0 dm sm dm sm Nether duzkrhke methods Nether duzkrhke methods Wands Wands W ustm cuspwam d sp avu W s 339 MRS d SD EVU mspiam 70Ver dde tn squeak ccks We a maHard ccks We a redhead ccks We a maHard ccks We a redhead aispwsm uaks We a rubberdLk Inheritance to the Rescue Interfaces to the Rescue Wk Duck ustm ustm Sw mquot 7evemeeem ta squeak 7evemee as an man 75am k W m d OK cermriemecs as a n as is mepuas We a rubberdL k but thequot 39 Mopck We a eetcv 77mate m Wmaae m cver e e ems mg cver e ems mg W Redhesdouck RubberDuck DmoxDuck ENSD EVU dispum d sp avu disp avU M No custm QuatkU quazk Problems So Far I Inheritance New hehayior not appropriate for all subclasses Polymorphism oyerriding Code duplication Maintenance nighunare Interfaces Ditto Another Design Principle Program to an interface not an implementation Interfaces will specify hehayiors Classes will implement speci c yersions Duck will use hehayiors represented by Interfaces and I Won t need to know lmPlementaDOn details Program to an Interface lt lthtetrste gt gt austm Quack Sguaak Muteguack austm oustm austw VUbber dutkle squeak dc Hakimlg or a 39t Cluazk lmDemems duzk ClLazkl g A Design Principle Identify aspects of your application that vary separate them from what stays the same I That is encapsulate the parts that vary Later they can be altered or extended without affecting those that dongtt For Duck class this means Pull quack and y hehayiors methods out create new set ofclasses for each hehayior Program to an Interface lt lthtetrste gt gt m0 Wags vu NW lmpeme ts duck who dc Hakim1g 77 can t nyl Benefits I Prograrnrning to a supertype InJava interface de nes a supertype I Encapsulated behaviors are reusable By other Ducks and by other types too Adding new hehayiors without modifying existing behaviors or classes using them Real zing the Bene ts Key is delegation Duck classes Will now delegate behayiors Delegate to a amPa r t balm held in a eld Instead of Impemaing them Nat directly in Duclt classes 7 separate small classes Encapsulated Behaviors Instead of set Ofbehavlors Vlewpomt Now a family of algonthms viewpoint One family for quacklng Could be compute sales taae by state One family for ylng Could be compute discount by customer category We can ux and match as desired MN classes rather than M x N and ugly duplicationsl Integrating Duck Behavior Dusk FWBehavlcr f vBehavlcr g aszehavla g aszehavla petrothuatm Quazk ehavlcr quatm swim dw sy DerfcrmF vU vBehavlcr m0 Mamet dutmke methods The Strategy Design Pattern De nes a family of algorithms Encapsulates each one Maltes them interchangeable Lets the algon39thm vary independently from the clients that use it A Third De 39gn Principle Favor composition oyer inheritance I See Item 16 111 Effective ava Second Edluon HAseA can be better than lseA Example A car has certain horsepower because ofits engine Temptation car as subclass of Engine Better car 11a an Engine delegates horsepower query to the engine Where is Strategy in our game We have a Paddle a Ball Blochs PowerUps and Walls When they collide special things happen PowerUps are a lot alilse but can Bump up score factor lfgotten hit paddle Bump it down lfmlssed hit bottom wall Do both I O neither and there Will be more kinds laterl 5 What about the Adventure game ng Character Troll Kmfe Weapon Queen BowAndAuow Axe setWeapon Sword
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'