Pattern concept
"Design mode helps you learn more from others' successful experience instead of your own failure."
Perhaps, the most important step towards the object-oriented design is the "design pattern" movement, this exercise is recorded into a book "design model". That book shows 23 solutions for specific types of problems. This book will use an example to introduce the basic concept of design patterns. This will arouse your interest in the "Design Mode" book you are reading Gamma et al., The book has become an important and almost essential "vocabulary" for programmers who are opposed to face-to-face programming.
The chapter behind this book describes the process of design evolution in an example. From the initial solution, according to reasonable reasoning and steps, it will eventually evolve into a more reasonable design. This example (an example of analog trash sorting) continues to evolve over time, you can think of it as a prototype, you are also designed for a certain solution, gradually evolving from an application for a particular problem. A flexible way to solve a certain type of problem.
What is the pattern?
At first, you can imagine how to be a particularly clever and keen approach to solve a particular problem. More specifically, many people solve a problem from different angles, and finally everyone puts forward the most common and flexible solutions. This problem may be you have seen before and resolved, but your method may compare the integrity of the way you will see.
Although they are called "design patterns", they are actually not limited to design. The pattern seems to be very far from traditional analysis, design and implementation; it is the opposite, the mode is reflected in the overall concept of the program, so sometimes it will appear in the analysis or an overview stage. This is an interesting phenomenon because the mode can be directly implemented by the code, so you may not want to use the previous model in detail or coded, (in actually you may not realize that you need a specific one before detailed design and encoding mode).
The basic concept of the pattern can also be seen as the basic concept of the design: adding an abstraction layer. Whenever you want to abstract something abstract, in fact, you are separating a specific detail, and a persuasive motivation to do this is to separate the changes from those constant. Another saying of this problem is that when you find some part of the program, you will want these changes to change to the program code for some reason. Do not only make the program more easily maintained, but it usually makes the program more easily understood (this will reduce cost).
In many cases, the most difficult thing to design elegance and easy maintenance is to find "A series of changes." (Here, "vector" means the maximum gradient - the largest part of the change - not Refers to the container class. This means that the most important thing is to find some part of your system, or find the highest cost. Once you find this series of changes, you can construct your design with focus.
The purpose of the design pattern is to separate the part of the code in the code. If you look at the design pattern, you will find that this book has actually told some design patterns. For example, you can think inheritance is a design pattern (but he is made by the compiler). By inheriting, you can make the object with the same interface (which is constant) has a unreasonable behavior (this is part of the change), the combination can also be considered to make a mode, it can be static or dynamically changed You are used to implement a class object, thereby changing the behavior of this class.
Different models in "Design Mode" this book: Iterator, you have already seen it. (Java1.0 and 1.1 self-righteousness is called enumeration); the container of Java 2 uses the term "Iterator)."). This approach hides the specific implementation of the container class when you need to traverse and select certain elements. By using an iterator, you can write a generic code for a sequence element without having to generate this sequence element. Thus, these generic code can be used for all containers capable of generating iterators. Pattern Taxonomy
After the design model, some people worry that the word "design model" is abused, because people have begun all what they feel good to be design models. After careful consideration, I divided the similar things in this series into several categories:
Rational (IDiom): How to make a specific function, write code for a particular language. For example, just like how you travers an array in C (you don't jump to the last element of the array at once).
Specific Design: In order to solve a particular problem, a certain method proposed. It may be a very clever design, but we don't expect it to become a general solution.
Standard Design: In order to solve a certain type of problem, a more generous design proposed, usually to meet its versatility by multiplexing.
Design Pattern: It is used to solve a major similar problem. Usually, after we use a standard design multiple times, it is found that a generic mode can be abstracted from these applications.
I think this distinguishes can help us look at these categories in a more comprehensive vision, so that they apply. However, this does not mean that a certain category is better than another. Trying to put each solution into design patterns, which is purely wasting time and is also a possibility of discovering (new) mode. Mode is usually produced over time in unpredvantages.
The analysis mode (Architectural Pattern) can also be added in the classification of those categories above.
Design Principles
(Moving from the slide to here)
When I collect opinions through my own electronic communication (Newsletter), many people will give me a lot of useful recommendations, but they are different from those scope discussed above. I realized that a list of design principles is at least as important as design constructs. However, there is another reason, you have these design principles you can use them to question the design of your suggest, and check these designs.
Try to make the Qiao Leading skills (do not feel weird on this principle) PrinciPle of Least Astonishment (Don't be astonishing).
Simplify the general problem, rare problem Possible (Rare Things Possible)
Consisters CONSISTENCY. This is already very clear about me, especially after Python: If you impose it to the programmer, the box box is not much used in solving the problem of the problem, the lower the programmer programming. And this web impact is not linear growth, but is a geometry of the geometry growth. DEMETER: "Don't talk to strangers." An object is best to only reference its own properties and its own method of parameters.
Subtraction Principle: When you can't get anything from a design, this design is completed.
Simplicity is more important than Generality. (This is another statement of the Occam's Razor. Its original words are "the easiest thing is the best"). A common problem is that many frames always emphasize versatility when designing, without considering practical systems. This leads to a large pile to make dazzled options, and these options are either not used, or if they are misuse or there is no use. Moreover, most developers have developed a special system. Many times seek versatility is not too much for them. The best way to seek versatility is to understand the specific example of the existing perfect mature. Therefore, this criterion makes it easy to choose a simple design in a simple design and general design. Of course, simple design is just a general design is also entirely possible.
Reflexivity (I recommend this term). An abstraction per class, each abstraction, one class. This guideline can also be called an isomorphism.
Independence, or orthogonality (Orthogonality). Independently express every individual idea. This criterion is the addition of Separation, Encapsulation and Variation. It is part of "low-coupling-high-cohesion" idea.
Once and only once (Once and ONLY): If the two codes do the same thing, it should avoid logical and structural repetitions.
When I first think about these design principles, I just want to summarize one or two so that you can use it directly when you analyze a problem. However, you can use other guidelines in the above list to check and analyze your design.
Mode classification
"Design Mode" discusses 23 different modes, divided into three classes according to purposes (these purposes around a variable specific situation). These three categories are:
Creating Creating: How to create an object. This usually includes details of the separation object creation, so your code does not depend on the type of object, and does not have to change the code when adding new types of objects. The Singleton mode that will be told below is a creation mode. The chapter later you will also see an example of the Factory Method and prototype mode.
Structural type: Designed to meet some of the specific constraints in some engineering. It works this: A set of objects are associated with other objects, and the association relationship between these objects is unchanged when the system changes. Behavioral: Refers to a program that handles a series of specific types of operations in a program. They encapsulate a series of operations, such as interpreting a language, fill in the form, traversing a sequence (like an iterator), or achieves some algorithm. This book is illustrated by the Observer and Visitor Mode (Visitor).
"Design Mode" has a part of one or more examples to illustrate these 23 modes, these examples are basically written with C (Rather Restric C , At That), sometimes using SmallTalk. (You will find this is not a big problem, because you can transfer those concepts from C or SmallTalk to Java. This book will re-explain the many modes of "design mode" in Java, because the replacement language brings a change in mode representation and understanding. However, here will not repeat the examples of GOF, because I believe that by working hard, we can design more easily understand. My goal is to make you know what is used for what is used and why they are so important.
I have already contacted these things for many years. I gradually realize that the model itself is actually a very basic organizational structure, not as complex as described in "design mode" (more simple and simple). The reason why I do this is because mostly said that the design mode (not limited to "design mode"), there is a lot of similarity on the structure applied by the implementation (the structure) applied to the implementation. Although we always try to avoid the implementation of implementation, it is replaced by interface, but here, I think it is more likely to understand these modes with "structural principles). I have tried to reclassify them with similarity of these model structures without adopting those categories in "design mode".
However, later I found that the problem solved by these modes will be more useful. I expect that this categorized method is different from the method of categorizing the INTENT in the Java Design Mode Manual (Design Patternal Scripter "). Although it is subtle but is very important. If the model is used to classify this method I said, I hope the reader (after learning this book) can identify the problem and find a solution.
In the process of continuous "Book Refactoring", I realized that if I changed some place, then I will change the place in the future (of course there will be a number of times), so I will go. All chapter number index, so that the future changes (this is the Numberless Chapter Pattern): Challenge, the development faces (challenge)
About program development, UML procedure, Extreme Programming.
Assess Value (Is Evaluation Valuable)? Ability Maturity Model (The Capability Immaturity Model):
Wiki Page: http://c2.com/cgi-bin/wiki?capabilityimumaturemodel
Article: http://www.embedded.com/98/9807br.htm
Research on Pair Programming:
http://collaboration.csc.ncsu.edu/laurie/
unit test
In a version of this book, I identified unit testing is essential (like all other books), but the JUnit at that time is too uncomfortable. At that time, I wrote a set of unit testing frameworks, which use Java's reflection (REFLECTION) to simplify some of the syntax required for unit testing.
Thinking In Java's third edition, I developed another set of unit tests to test the output of the examples in the book.
During this time, JUnit adds syntax for support unit testing, which is the same as me in previous versions of this book. I don't know how much I have a change in (JUnit), but I am very happy that JUnit has made these changes so I don't have to maintain my own test frame (but you can still find it here.
), I need to do this to recommend this principal standard (refer to JUnit)
).
I introduced and describe the programming style of JUnit in Chapter 15, I think that the code is "the best practice" in the Thinking In Java. The unit test related to this book is provided in that chapter (but this book is usually not included in the body). When you download this book, you will find that the code is included in the case.
Test code location
(From bill) These are 啥 玩 玩? Is it not written yet?
Public (public): In the Test subdirectory; unless Package (not included in Jar).
Featuring Package Access: The same package, a subdirectory of a library (not included in JAR).
Private permissions: (white box test). Nested, Strip Out, or JUnit Plugin (ADDONS). table of Contents
