Thinking in Patterns with Java V0.9: Chapter 16: Complex interactions: TIPatterns.htm#_Toc41169753
1, Sections:
Externalizing object state 113
Memento. 113
Complex interactions 114
Multiple dispatching. 114
Visitor, a type of multiple dispatching 117
Exercises
2, The main content and feeling:
Memento Pattern isn't described in this book(So I don't write a diary of Chapter 16: Externalizing object state), I must learn it in other place.
After twice reading of chapter: Complex interactions, I got little from the book. Don't like Thinking in Java, in that book, there is detail explaination after every example. But, it isn't given explaination in this chapter's two examples. This book is only Version0.9.
1), What is Multiple dispatching? I knew it from this point: "Remember that polymorphism can occur only via member function calls, if you want double dispatching to occur, there must be two member function calls: the first to determine the first unknown type, and the second to determine the second unknown type."
Just describe it use the example in the book below:
|
|
Here, a scissors vs. a paper:
s Item = new Scissors();
p Item = new Paper();
s.compete(p); // the first(method compete()) to determine the first unknown type(Scissors),
//In the method "compete()", the second method is called
p.eval(s);// the second(method eval()) to determine the second unknown type(Paper),
Why does the first(method compete()) NOT to determine the second unknown type(Paper)?
The key is this statement above:
polymorphism can occur only via member function calls
When the method compete() be called, the type of the object that call this method is determined, "Item" "s" is a "Scissors".
The second method eval() is same as the first method complete().
2), Visitor, a type of multiple dispatching
After know the Mutiple dispatching, Vistor Pattern is understood soon. Because, it "builds on the double dispatching scheme shown in the last section".
There is a point need to note, the purpose of using Vistor Patterns is changing the method's behavior without modifying original hierarchy.
I explain this using the example in the book too:
In this example, Flower classes hierarchy can't be changed. And can determining it's type by calling it's method: accept(Visitor v);
Although Flower classes herarchy can't be changed, but Visitor classes herarchy can be changed, so there are two types of Visitor be created, one is "StringVal", another is "Bee". And, the second Type be determined in this method below:
v.visit(this); //"this" is a Flower, when the "v" call visit() method, its type be termined. And, different type Vistor visit(this) can get different behavior, that just we want to get.
3), Multiple dispatching can be replaced by a table lookup, just look it in the exercise 3.
I think there are two type of Map will be used. it is one: key is class, value is another map; another map: key is class, value is outcome.
4), At this point, I suddenly think, I guess, Bruce thinks the Design Pattern isn't a very import thing in his software design, I feel his words outside this book is just saying: many of these "Dsign Patterns" is redundant, a basic idea of mine be divided into these too many Patterns, this basic idea is: No pattern is patterns for all.
This is only my guess, my feeling. If my feeling is right, maybe, we maybe can't see a version1.0 of this book:(
My english language and program knowledge is poor, if I make any mistake, please tell me: mdx-xx@tom.com
3, Questions about programming:
1), The answer starts with something you probably don’t think about: Java performs only single dispatching. That is, if you are performing an operation on more than one object whose type is unknown, Java can invoke the dynamic binding mechanism on only one of those types. This doesn’t solve the problem, so you end up detecting some types manually and effectively producing your own dynamic binding behavior.
2), How to do if there are more than double dispatching in the above?
Like below?
a.F(b);
b.G(c);
c.H(a);
...
3), All the exercises.
4, Questions about english language:
1), Strange words:
compete, Scissors, Outcome, primary, dilemma, virtualize, bound, Gladiolus, Runuculus, Chrysanthemum, Inhabitant, Dwarf, Elf, Troll, Jargon, InventFeature,
Each Inhabitant can randomly produce a Weapon using getWeapon( ): a Dwarf uses Jargon or Play, an Elf uses InventFeature or SellImaginaryProduct, and a Troll uses Edict and Schedule.
syntactic, simplicity,
2), Difficult sentences:
The easiest way to do this is to create a Map of Maps, with the key of each Map the class of each object.
******************************************************************
The class diagrams of two examples in the book:
1),//: multipledispatch:PaperScissorsRock.java
2),//: visitor:BeeAndFlowers.java
incomplete