Session 2A: Design PatternsWednesday 14 March 2007

Sitecore for Experts “Sitecore skills for real men (and Max ;-))”

Introduction to the subject

1. Decorator2. Factory & Façades3. Observer

QuestionsHomework!End

Today’s Program

Refresh of the subject

1. Prototyping & Commands2. Async Client3. Algoritmic / Concurrency: Semphore

QuestionsEnd

Next Month’s Program

Introduction

• 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

• American architect• Building on huge projects(even cities!)

Christopher Alexander

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

Two computer scientist worked on this idea:

In the 80s

Kent Back

Founder:eXtreme Programming

Agile Programming

Ward Cunningham

Founder:eXtreme Programming

Wiki’s

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

• 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

• 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

Design patterns aren’t...1. Hard to understand2. Codesnippets you directly apply on your

code3. Something you’ll learn in a day4. Answer to everything...

Last but not least...

Decorator

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

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

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

Class SantaClaus : Person{

SantaClaus(Person);

public Person Person { get; set; }public Color Nose { get { return Color.Red;} }

}

Introduction: implementing the pattern

Introduction: the UML again

• 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

Simplify access to data:• CustomItem:

– Security: UserItem / RoleItem– Content: MediaItem– Presentation: DeviceItem / LayoutItem– Structure: TemplateItem / MasterItem

• CustomField:– HtmlField– LinkField– SecurityField– XmlField

Sitecore usage

• Functionality on runtime• Easily to implement, no ‘rocket sience’• Provides better interface for libraries• Code readability improves

Advantages of the pattern

• 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

• 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

Factory & Façades

Factory: Building objects.

Introduction: Factory

Class Factory {public ICar CreateCar(CarType);public CarChair CreateCarChair(Material);public Wheel CreateWheel();

}

Introduction: Factory

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

Introduction: Façade

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

• 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

• 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

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

• Sitecore.Configuration:Class: Factory

Sitecore usage

• Factory: Construction on runtime• Factory: Construction without writing

complex code• Façade: Hiding implementation and

communication details of other subsystems

Advantages of the patterns

• 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

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

Factory method:– http://en.wikipedia.org/wiki/Factory_method_pattern

Façade– http://en.wikipedia.org/wiki/Fa%C3%A7ade_pattern

Additional reading

Observer

• You want to be updated when something changes

• For example:– Someone places a bid on Ebay– A user clicks on a button

Introduction

1. First initialize a dispatcher2. Add observers / listeners3. Send notify to:

1. All listeners2. Listeners with a specific signature

E.g.: Those who accept specific arguments

Introduction: the steps

• 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

• Item handling (creating, editing, deleting)

• Publishing (before, during, after)• Shell (Window events)

Sitecore usage

• No needs of creating not existing relations

• When good implemented:– Incredible fast– Thread-safe

• Native support in .NET languages

Advantages of the pattern

• Sometimes hard to imagine• Hard to debug

Disadvantages and possible problems

• 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

This is your last change…

Questions?

1. 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).

2. Provide me a sample implementation of another comparer and explain in approx. 15 steps what the system does to retrieve end return the comparer.

3. 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

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.nl

The presentation is part of LECTRIC / Alex de Groot but can be used without any premission.

The end…