Thinking in Patterns with Java V0.9: chapter 9: too many: TIPatterns.htm#_Toc41169721
1, The sections name of today's learning;
Flyweight: too many objects. 66
Decorator: too many classes. 69
Basic decorator structure. 70
A coffee example. 70
Class for each combination. 70
The decorator approach. 73
Compromise. 78
Other considerations. 82
Exercises. 83
2, What is it talk about in these sections and my comments and feeling for the content;
I have never felt the design pattern's importance so strong until I read this chapter, especially the section Decorator: too many chasses.
1), Flyweight: too many objects. 66
For my understanding, the key of Flyweight pattern is: put all the objects of a class into one object which I named it "all_in_one", get the any object of many object from this "all_in_one" object by passing the "index" of any object of many object into this "all_in_one".
By running the modified example in this section, I am sure it's really true.
I modified "size = 1000000" to "size = 5000000" in flyweight:ManyObjects.java, and ran it, it reported:
|
The same "size = 5000000" in flyweight:FlyWeightObjects.java works well, and the running time is less much than the running time in flyweight:ManyObjects.java with "size = 1000000"( with a less size, it works.).
At the end of this section, Bruce warn us don't do a "premature optimization" by using flyweight pattern unless discovering performance bottlenecks of too many objects by using a profiler tool, I think if I haven't misunderstood his words.
2), Decorator: too many classes. 69
Just this pattern give me so strong of pattern's importance. And, the example of "coffee shop" posted by Bruce is so natural and proper. I can understand the meaning of this pattern by this example even the program detail isn't very clear for me.
For my understand, I put up another example for this pattern: "man", then decorate "man" with "good man", "wise man", "old man", "strong man", at last, a strong old wise good man appears.
Without the Decorator pattern, there will be many class need to be created in Bruce's coffee shop example.
With the Decorator pattern, there are two approachs, one is "pure" decorator, and another is compromise which mixes the approach of without decorator and with decorator.
In most real stiuations, a compromise way should be taken.
This is really a book which "Problem-Solving Techniques using Java".
The uml classes diagrams of these three approachs of solving too many classes problem which from this book is at the end of this diary.
3, My questions about the program itself;
1), "implicit this pointer in method calls, the “this index” is passed in as the first argument.", how does the implicit "this" pointer work step by step in JVM?
4, My questions about the english language;
1), Strange words:
flyweight, odd, in the company of, hack, prohibitive, excessive, externalize, pretend, untenable, admonishment, guesswork, layered, refer to as, account for, go down to, espresso, latte, teas, whip, decaf, sizeable, Mocha, steamed, foam, conform to, mug, assembling, arduous, Compromise, present, get away, syrup, Follow the compromise approach to create a menu consisting of a Margherita, Hawaiian, Regina, and Vegetarian pizzas, with toppings (decorators) of Garlic, Olives, Spinach, Avocado, Feta and Pepperdews. Create a Hawaiian pizza, as well as a Margherita decorated with Spinach, Feta, Pepperdews and Olives. detaching, beverage
2), Strange sentences:
1>, Firstly, the combinations are fixed statically so that any combination a customer may wish to order needs to be created up front.
2>, However, the implications to the all decorator or compromise approaches are the same - one extra class is created.
=============================================================================
Basic decorator structure
******************************************************************
Class for each combination
******************************************************************
The decorator approach
******************************************************************
Compromise
