Thinking in Patterns Chapter 2: The pattern concept

Thinking in Patterns with Java V0.9:  Chapter 2: The pattern concept: TIPatterns.htm#_Toc41169683

1, The sections name of today's learning;

    What is a pattern?. 15

    Pattern taxonomy. 17

    Design principles. 18

    Classifying patterns. 19

    The development challenge. 21

    Unit testing. 21

        Location of test code. 22

 

2, What is it talk about in these sections and my comments and feeling for the content;

  At first, Bruce introduce the famous GoF's Design Patterns which show 23 design patterns, the very good aspect in that book is: it shows a evolution process by a given example, tracking this example's step, we can see how the design patterns be applied in an application.

  1), In the section What is a pattern, Bruce gives us a definition of pattern in a wider area.

  He tells us, Pattern is the general good way for resolving a class of problems, and this way has used by many times.

  Design Patterns isn't only tied with design phase, sometimes it appears in analysis, or implementation phase.

  The concept of Design Patterns is also proper for designing program, the same concept is "separate things that change from things that stay the same".

  Again, Bruce put up with his viewpoint of the little part of a system cost the most resource. He calls this as "the vector of change." My understanding is: from the math's aspect, suppose Y=kX, if "k" is very big, then X plus a little, but Y will plus a lot. So we should use our Design patterns around these most import but with less code's part of the system.

  In the rest part of this section, Bruce tells us the goal of using Design Patterns is "to isolate changes in your code", from this pointview, "inheritance", "compostion", "iterator", these terms in the program which we have used before, all these can be a kind of "Design Pattern".

  2), Section Pattern taxonomy.

  According the degree of using pattern in a system, the ablility of reusing the design, Bruce put up with his categories in this aspect. From the less reusing to the most reusing, it is: Idiom, Specific Design, Standard Design, Design Pattern.

  3), Design principles.

  I think, every principle here can be extend to be a chapter, and this section can be written to a book. Because the less programing experience of mine, I can't understand some principle here, especially like: Principle of least astonishment (don’t be astonishing); Make common things easy, and rare things possible; Law of Demeter; Once and once only.

  I can't write anymore in this section, maybe it need me to add a new goal called: understand Bruce's Design principles:)

  4), Classifying patterns.

  The 23 patterns in Design Patterns written by C++ or smalltalk are classified into three purpose: Creational, Structural, Behavioral. Bruce will revisit these 23 patterns with Java. And put up with his own examples about it. I always like the examples in Thinking in Java. So I think I will get surprised in this book's examples too.

  With Bruce's own mind of classifying all these 23 patterns, he put up with two kinds of classifying methods, and all these two methods are different from GoF's.

  The first method is according to the structure of implementations. At last, Bruce chose the second method:  according to "the problems they solve". So, this will be a practical and very useful book. I like Bruce's choice:) I think if I meet some kind of design problem, I can find a proper patterns in term of the problem's class.

 

  5), The development challenge

  I don't understand what is Bruce talking about in this section, he give some development methods and some internet resource. These terms is concerned with Design Patterns? I don't know.

  6), Unit testing

  In this section, I can know, at first, Bruce use his own testing framework, later, Junit get well, so he simply recommend the defacto standard-Junit. Bruce says he don’t know how much influence he may have had on Junit's change. I think Bruce is proud for his unit testing framework in his early book of Thinking in Patterns 

If I haven't misunderstood this section's words:) He is a frank man, I think.

 

4, My questions about the program itself;

  1), Most of Section Design principles I can't undersand well. I know this is copied from Thinking in Java Edition 2, but I haven't understood these then. Maybe, seeing the translation of HouJie's can help me to understand these?

 

5, My questions about the english language;

  1), Strange words:

ibid, whet, mandatory, vocabulary, adequate, flexible, insightful, work out,

completeness, embody, realm, gradient, put another way, focal, taxonomy,

pollution, synonymous with, succession, perspective, turn out,  proposed,

astonishment, astonishing, pile onto, demeter, Subtraction, dizzying, quest,

quantity, chapter, indent, intent, accidental, Variation, complement, aforementioned,

orientation, illuminating, decent, occur to, other than, in favor of, definitely

maxim, maxim, little-known, recommend, defacto, adequate, not yet, strip out

  2), Strange sentences:

  1>, This should whet your appetite to read Design Patterns by Gamma, et.

al., a source of what has now become an essential, almost mandatory, vocabulary

for OOP programmers.

  2>, Here, ?vector? refers to the maximum gradient and not a container class.

  3>, One of the events that?s occurred with the rise of design patterns is

what could be thought of as the ?pollution? of the term ? people have begun to

use the term to mean just about anything synonymous with ?good.?   

  4>, So, this principle acts as the tie breaker between otherwise equally viable design alternatives.

  5>, I believe this is a subtle but important distinction from the way Metsker organizes the patterns by intent in Design Patterns Java Workshop (Addison-Wesley 2002), because I hope that you will then be able to recognize your problem and search for a solution, if the patterns are organized this way.

  6>, When you download the code for this book, you will find (4/9/2003: Eventually, not yet) unit tests along with the code examples whenever possible.

                                           incomplete