This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
It's not necessary for there to be an association in the class model, between the Originator and CareTaker.
The class diagram is a static structure diagram and an association represents a static relationship.
There needn't be a static relationship between the Originator and CareTaker for an correct implementation of this pattern.
The relationship in the sequence diagram models dynamic behavior between objects, which is why in that diagram there must be an interaction between the Originator and CareTaker objects.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
OK, but since the page doesn't show a sequence diagram they could have drawn a dependency relation in the class diagram. In my opinion, this would increase understanding of the relationship between these classes, which is the goal of the class diagram in this case.
Joined: Aug 08, 2010
Could you elaborate on why Originator and CareTaker don't need any relationship?
Isn't Originator and CareTaker relationship similar to the factory pattern where client (Caretaker) asks for an object (Memento) from a factory (Originator)?
Exactly, and that is why I think a dependency relationship should have been drawn in the class diagram.
As always, you don't have to follow the book with design patterns: in your application it might be better to split the Caretaker responsibility into 2 classes: one that extracts the Memento from the Originator, and one that stores the Memento. No good example comes to mind though.
Joined: Aug 08, 2010
Sorry, I wanted to ask Jelle about his/her opinion, but unfortunately I inserted the wrong name...
I'm no UML expert, but I think there is some confusion in what 'static' means; a class diagram should describe the static structure of classes. I think 'static' here is meant as opposed to an object diagram, which describes what the structure of a set of objects could be at a certain point in time.
However, I don't think 'static' means that the relationships described in the class diagram need to be immutable, otherwise you could only describe inheritance in your class diagram, and not composition or aggregation, as composition and aggregation are dynamic relationships.
Therefore I think it is valid to include dependency relationships in your class diagram, even though the relationship is not 'static' as in technically immutable.
If in your application for some reason you decide to include an extra class that gets the Memento from the Originator and hands it over to the Caretaker, and when needed extracts it from the Caretaker to hand it back to the Originator, then ofcourse you would not draw a relationship between Caretaker and Originator.