Session 2A: Design Patterns Wednesday 14 March 2007

1. Sitecore for Experts“Sitecore skills for real men (and Max ;-))” Session 2A: Design Patterns Wednesday 14 March 2007

2. Today’s Program Introduction to the subject Decorator Factory & Façades Observer Questions Homework! End

3. Refresh of the subject Prototyping & Commands Async Client Algoritmic / Concurrency: Semphore Questions End Next Month’s Program

4. Introduction

5. Less computers Feminism wasn’t fully propagated ;-) Elvis and Bob were still alive Buildings could be constructed without any environmental restrictions Everything was better in the 70s

6. American architect Building on huge projects(even cities!) Christopher Alexander

7. Christopher looked at his work and discovered: Building and infrastructure design have some many repeatable steps. Those steps have got the same results Simplified results to unified building ‘blocks’ Proved their existence afterwards Patterns were born! Building patterns

8. Two computer scientist worked on this idea: In the 80s Ward Cunningham Founder:eXtreme Programming Wiki’s Kent Back Founder:eXtreme Programming Agile Programming

9. Ralph Johnson, Richard Helm, Erich Gamma, and John Vlissides 90s: Gang of Four • Gamma presented the others his Thesis work on OOP-SLA ’90 • 4 years of work contributed to:Design Pattern: Elements of Reusable Object Oriented Software

10. Design Patterns are part of regular IT- education All original patterns still exists(!!) Some are added and some slightly improved Used as base for nearly all applications Invented the idea of Application blocks(design pattern on Architecture level) Sitecore uses ‘m... These days

11. Fundamental PatternsFeeding the general need of a developer such as Interface design Creational PatternsPatterns which gives you handhelds to construct your objects Structural PatternsThe design of the relations between objects Behavioural PatternsWays to cocommunicate between objects Concurrency PatternsBest pratices on implementing concurrency(not just threads!) Pattern Categories

12. Design patterns aren’t... Hard to understand Codesnippets you directly apply on your code Something you’ll learn in a day Answer to everything... Last but not least...

13. Decorator

14. Sometimes you’ve got a object which identifies itself by a property / action. Example: Santa Claus: a Person with a red nose... Introduction: the case

15. Santa has the same properties like every Person: Class Person { public string FirstName { get; set; } public string LastName { get; set;} public DateTime BirthDate { get; set; } } Introduction: the case

16. Santa is also Person: Class SantaClaus : Person { public Color Nose { get { return Color.Red;} } } Yep I’ve ‘Decorated’ that Person, he’s now Santa. Introduction: the solution

17. Class SantaClaus : Person { SantaClaus(Person); public Person Person { get; set; } public Color Nose { get { return Color.Red;} } } Introduction: implementing the pattern

18. Introduction: the UML again

19. GUI componentsBuilding up functionality:Window, WindowWithBorder, WindowWithBorderAndScrollBar StreamsRuntime base functionality:Stream, TextStream, IOStream, NetStream Security layersHiding field which shouldn’t be accessed by other developer. Make your base private and just display the fields you want! Practical usage

20. Simplify access to data: CustomItem: Security: UserItem / RoleItem Content: MediaItem Presentation: DeviceItem / LayoutItem Structure: TemplateItem / MasterItem CustomField: HtmlField LinkField SecurityField XmlField Sitecore usage

21. Functionality on runtime Easily to implement, no ‘rocket sience’ Provides better interface for libraries Code readability improves Advantages of the pattern

22. More classes, might be (a bit) slower Original class doesn’t define the possiblitiesE.g.: What kind of CustomField is X? Requires a well organized object structureE.g.: Should be possible but where is that Decorator? Owwwww.... There it is...... Disadvantages and possible problems

23. General http://www.dofactory.com/Patterns/PatternDecorator.aspx http://en.wikipedia.org/wiki/Decorator_pattern Sitecore specific: Alexey Rusakov’s blog: http://www.alexeyrusakov.com/sitecoreblog/2007/02/04/Custom+Item+Sitecore+API+Pattern+Explained.aspx http://www.alexeyrusakov.com/sitecoreblog/2007/02/08/Custom+Field+Sitecore+API+Pattern+Explained.aspx Additional reading

24. Factory & Façades

25. Factory: Building objects. Introduction: Factory

26. Class Factory { public ICar CreateCar(CarType); public CarChair CreateCarChair(Material); public Wheel CreateWheel(); } Introduction: Factory

27. Façade: Doing something somewhere else you don’t want to know about. Introduction: Façade

28. Class Façade { public CRMConnection crm { get; set; } public BizTalkConnToSAP bizSap { get; set; } public Façade() public bool ExistsInSapAndCrm(Person p) { return crm.Exists(p) && bizSap.Exists(p); } } Introduction: Façade

29. Building objects which are hard to construct Construct object which need some more actions direct after construction Examples: Configreaders Document creation Parameters as a part of a connection Practical usage: Factory

30. You don’t want to know anything about the other subsystems You want to make sure this is really ‘the end’ of the other subsystem So communications starts and stops here Practical usage: Façade

31. Combining: Factory & Façade • Software is built on blocks(subsystem) • Factories allows you to create objects for communication with all different subsystems (interfaces) • Those interfaces are façades • Or sometimes objects are constructed using façades when they need data from different sources

32. Sitecore.Configuration:Class: Factory Sitecore usage

33. Factory: Construction on runtime Factory: Construction without writing complex code Façade: Hiding implementation and communication details of other subsystems Advantages of the patterns

34. Factory: No abilities to control the amount of instances Façades: As you’re hiding details, you might do not efficient reuse your code Disadvantages and possible problems

35. Sitecore.Configuration.Factory might also contain another pattern: Abstract Factory. Not described as it would take to much time. See also: http://en.wikipedia.org/wiki/Abstract_factory_pattern Last note

36. Factory method: http://en.wikipedia.org/wiki/Factory_method_pattern Façade http://en.wikipedia.org/wiki/Fa%C3%A7ade_pattern Additional reading

37. Observer

38. You want to be updated when something changes For example: Someone places a bid on Ebay A user clicks on a button Introduction

39. First initialize a dispatcher Add observers / listeners Send notify to: All listeners Listeners with a specific signatureE.g.: Those who accept specific arguments Introduction: the steps

40. All systems which run more then one independant proces: To keep different threads synchronized Connect between object who haven’t got a direct relation Practical usage

41. Item handling (creating, editing, deleting) Publishing (before, during, after) Shell (Window events) Sitecore usage

42. No needs of creating not existing relations When good implemented: Incredible fast Thread-safe Native support in .NET languages Advantages of the pattern

43. Sometimes hard to imagine Hard to debug Disadvantages and possible problems

44. General http://en.wikipedia.org/wiki/Observer_pattern http://www.dofactory.com/Patterns/PatternObserver.aspx Sitecore specific: http://sdn5.sitecore.net/Articles/API/Using%20Events.aspx Additional reading

45. This is your last change… Questions?

46. Find out what Sitecore.Data.Comparers. ComparerFactory does. Write it down in at most 200 words so anyone who isn't technical understands it (my and your mum). Provide me a sample implementation of another comparer and explain in approx. 15 steps what the system does to retrieve end return the comparer. Find out what the Abstract Factory Pattern is. Promote 2 method in the whole Sitecore API which might have implemented this pattern. Explain in at most 250 per method why and how. You may make 1 drawing which applies for both methods. Sent it to a.degroot@lectric.nl before Monday 2 April. Homework

47. Thank you for your attention! And please, think about it and spread the word… Mistakes, corrections and additions can be mailed to Alex de Groot: a.degroot@lectric.nlThe presentation is part of LECTRIC / Alex de Groot but can be used without any premission. The end…