02-DP-Strategy.pdf

Design Patterns: Strategy 43AON3150 Software Engineering Hogeschool PXL – Elfde-Liniestraat 24 – B-3500 Hasselt www.pxl.be - www.pxl.be/facebook It started with a simple SimUDuck app New killer feature: flying ducks Flying Ducks Something went wrong  RubberDuck quack() { // sq...

Design Patterns: Strategy 43AON3150 Software Engineering Hogeschool PXL – Elfde-Liniestraat 24 – B-3500 Hasselt www.pxl.be - www.pxl.be/facebook It started with a simple SimUDuck app New killer feature: flying ducks Flying Ducks Something went wrong  RubberDuck quack() { // squeak} display() { // rubber duck} fly() { // override to do nothing } Let’s try interfaces  Some observations Flyable/Quackable destroy code reuse Change is the one constant in software development Design Patterns provide a way to let some part of a system vary independently of all other parts  Design Principle 1 Indentify the aspects of your application that vary and separate them from what stays the same. Applied for Duck problem Design Principle 2 Program to an interface, Not an implementation. Fly behaviors Quack behaviors Integrating Duck behavior Abstract class Instance variables hold reference to behavior at runtime performXXX – Delegate to behaviors Subclasses constructor initialize behaviors The Big Picture on encapsulated behaviors  Design Principle 3 Favor composition over inheritance  The STRATEGY pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.  UML Bron: http://www.dofactory.com/Patterns/PatternStrategy.aspx  Have I seen this before? interface IArtistRepository { IList GetAll(); void Update(Artist artist); } public class ArtistService { private IArtistRepository _artistRepository; public ArtistService(IArtistRepository repo) { _artistRepository = repo; } }