Mode and XP
Joshua Kerievsky, gigix translation
Overview
Mode and Extreme Programming (XP) are software design, and developers provide assistance that cannot be measured with money. But so far, XP has a large number of refactoring, and only words on the pattern are not mentioned. In this article, I asked "Why" and finally describes how to achieve XP in XP, and how XP becomes better because it contains the use of patterns.
Thank you
Thank you very much for Kent Beck, Martin Fowler and Ward Cunningham, who made friendly comments for this article.
-------------------------------------------------- -------------------------------------------------- ----------------------------
When we are still knowing, we started our programming career. The software produced also reflects our lack of experience: the code we created bloated, misfortune, fragile, difficult to maintain, difficult to expand. Over time, we have become a better software designer: we learn from technical writers, experts, and we learn from your own mistake. Now we write software with highly flexible software, which adapts to a wide range of and robust. When you are requested to write a new system, we know that the current and future needs so we can design software to handle current and future needs.
At this stage of software development, extreme programming tells us that we often have over-engineer. We learned too much from your own mistakes. We don't want to repeat these errors, so we have made a lot of effort in the early days of the system lifecycle to create flexible and sturdy design. Unfortunately, we didn't realize that if this system never requires this degree of flexibility and strongness, then all our work is meaningless. We are over-designed.
I have also been over-designed. To be honest, sitting with other designers in a room to consider how to design software to accommodate many current and future needs, this is indeed a pleasure. We have learned all things - especially those best experience - applied in the design. We often know that the list of demand will change, but users or customers always change demand. However, we believe that we can design the software enough to make the software enough to make it possible to change all demand changes.
Typical overfront design.
Today, extreme programming will tell you how stupid approach. XP said that we must let the design appear, not what will look like. XP said, "Do the simplest thing that can work", because "you will no longer need it." In addition, Kent Beck said:
You need to choose the best working method in a value system that emphasizes communication, simple, feedback, and courage so that you can bravely detach it. [Beck1 00]
agree. But now I have to mention my friend NORM KERTH. NORM has extensive experience and experience in the field of software development. I asked him "What idea is to XP" a year ago. He says:
I like everything in XP. I care about: What else is not in XP. [Kerth 99]
At that time, I only thought that Norm was a conservative. But now I can't determine it. XP is significantly lacking is the use of mode of experience. Although some XP founders help build a model community, there is no firm clear instruction mode to adapt to XP.
At first, this has not been confused. But now, I really feel confused.
I am confused because I am in XP and mode experiences let me believe that the mode works better in XP scenes; and when XP contains mode, XP will work better.
This requires some explanation. I will start from the description of my own mode of use and XP. Since 1995, I started to immerse into the mode. I have learned a model literature, hosted a weekly mode learning group, using mode design and development software, and perform organization and operation of UP (a international academic conference on the use mode). Say that I am "passionate model" is really a conservative statement.
At that time, like a lot of people in the first learning model, I have a little desire to use them. This is not a good thing because it will make your design more complicated than needed. But I didn't realize this until I started learning reconstruction.
Probably in 1996, I first exposed to reconstruction. I started experimentating it and quickly observed that I left some of my principles I learned in Mode study.
For example, the milestone book - "Design mode: The foundation of the object-oriented software" - one of the principles is:
Programming for interface, not for implementation programming. [Ghjv1 95]
The authors of "design model" have made a very wonderful job to explain why we need to follow this suggestion. Almost in all modes, you discussed how your software becomes lacking and modem performance when you program a particular implementation. Almost every time it is an interface to help.
But what if we don't need flexibility and modification, what is the situation? Why do we want to expect some need to never appear during design? This is my awareness. So I subsequently recorded this Java skills:
Do not separate classes and interfaces
I used to add a "i" after my interface name. But when I continued to learn more reconstruction technology, I began to see a wise practice: designing the class name and interface name. Here are the reason: During the development process, you know that you can use an interface to make some things flexible (make it diversified), but you may now do not need to achieve diversification. So, put down the "Over Design" of the forecast, you still keep it simple, still put things in a class. In some places you will write a method statement to use this class object. Then, a few days, a few weeks, after a few months, you clearly "need" an interface. So you convert the original classes into an interface, create an implementation class (implement a new interface), and keep your original statement unchanged. [Kerievsky 96]
I continue to learn similar courses similar to reconstructed, gradually, I started to change. I no longer take into account the use mode. Now, I am more sensible: if a pattern can solve a design problem, if it provides a way to implement a requirement, I will use it, but I will start with the simplest implementation of the model that can be encoded. Later, when I need to increase or modify, I will make this achievement more flexible and stable.
This new method of this mode of use is a better way. It saves my time and makes my design easier.
Since I continue to learn more about XP knowledge, I will soon began to consider such a fact: those who know "XP is" and "How to work" will not mention the mode. It seems that the focus has all been rebounded from development. Construct a little, test a little, refactor, then repeat.
So, what is wrong?
The general answer I received is: the pattern encourages excessive design, and the reconstruction keeps the things simple, lightweight.
Now, I like to refactor with anyone else - I reviewed two manuscripts on this topic of Martin Fowler, and then know that the reconstruction will become a standard. But I still like the pattern, I found the model in "helping people learn how to design better software" is a priceless treasure. So, how can XP does not include mode? !
I carefully wrote my uneasiness on Portland Pattern Repository. I asked: Whether the perfect XP mode should be composed of programs and instruments that don't know the model, whether they should completely depend on the reconstruction "Let the code go to it." Ron Jeffries, the most experienced XP practitioners in the world, arguing with me, and writing this: An initiator cannot listen to the code. He needs to learn the pattern of code quality (in a general sense). He needs optimistic code (and, I guess, poor code) so that he learns to write a good code.
A problem - I mean a possible problem - Yes, the current mode is used to help improve the quality of the code. I think Beck's SmallTalk Best Practice Patterns will help because they are very small models. I want to design patterns more doubts because patterns and discussions sometimes become quite large, and they may cause a huge solution that looks reasonably. Martin Fowler's wonderful analysis model is also the same: a large-scale solution is selected when you can choose a small-scale solution. [Jeffries 99]
A very interesting view of the pattern. Although I have seen the model can be smart, it can be used, but RON looks that they are dangerous, because they "make huge solutions look reasonably". Other places, Ron observes a often what happened: how people in the first learning model are over eager to use them.
I can't agree with this observation result. Just like any new thing - or even XP -, people may be too eager to use them. But is the model really encourages using a large-scale solution when you can use a small-scale solution?
I think this depends mainly on how you define, use mode. For example, I observed many models of primary users, they think that a pattern is identical to its structural map (or class diagram). Only after I pointed out that "mode can be implemented in different ways as needed", they have begun to find that these pictures are only a way to implement the model.
The implementation of the model is simple and complex.诀窍 是 是: Discover the problem of the pattern, compare this problem with your current problem, then the simplest implementation (solution) is compared to your question. When you do this, you will not use a large-scale solution when you can use a small-scale solution. You got the best balance to solve the problem.
Difficulties may appear when people do not have a good training. Ron mentioned that people's way of use is "now constructed" - this is to say how they communicate with the authors. I agree to have some shortcomings in the mode. There are a lot of books about the model, you can spend some time to understand the problem of the pattern, so you can select mode according to your own specific needs.
This choice is extremely important. If you have selected the wrong mode, you may be over-design or just put your design together. Experienced models will also make mistakes and often see such results. But these experts have other patterns as equipment, which can help them face their own mistakes. So they eventually replaced themselves to the model that they really needed to be less ideal.
So, how will you become an experienced model? I found that unless people are involved in a large number of patterns, they may have fallen into them, excessively use them and use them over-designed dangers.
But is this a reason for avoiding the mode of use?
I think, no. I found that the model is so useful in such a project, so that I can't imagine that they do not use them to design and develop. I believe that the thorough study of the model is very worthwhile.
So, XP keeps silent because I feel that they will be misused?
If this is the case, maybe the problem has become: How do we use wisdom in the mode, and avoid the mode in the XP development scenario? Here, I think I have to go back to "design mode". In the "conclusion" chapter, "What will be brought about by design mode," Reconstructive Target "section, the author wrote:
Our design model records many reconstructed design structures. These modes can be used to prevent future reconstruction in the initial stage of design. But even after the system is built, you can use these modes, they can still teach you how to modify your system. Design patterns provide a goal for your reconstruction. [GHJV2 95]
This is what we need: the target of reconstruction. This is the bridge between reconstruction and mode. It describes how my own use mode is made: from the simple start, consider the mode but keep them at the secondary position, small-scale reconstruction, only when the real need mode is actually transferred to mode.
This process that requires training and careful judgment will adapt to the best habits contained in XP.
Moreover, this way is clearly different from "Deliberately do not know or do not use the model, only relying on reconstruction," is very different.
Danger only relying on reconstruction is: there is no goal, people may make the design small progress, but their comprehensive design will ultimately damage, because this method lacks sequential, simple and effective, and smart mode of use can be developed Have these.
Quote Kent Beck's own words: The pattern generates the architecture. [Beck2 94]
But the pattern does not guarantee discipline use. If we use too much in the design, premature use, we will return to over-design problems. Therefore, we must answer this question: "When the designed life cycle is safe?" Please recall the reference to "design mode" on the design:
These modes can be used to prevent future reconstruction in the initial stage of design.
This is a smart claim. If we don't know the basic rules of "When to configure a pattern", then we can easily fall in the early design period.
Once again, the problem is all set together: How to match the problems in the project with a suitable pattern.
Here, I have to tell my experience in developing software for different industries.
There is a customer asking me to construct software for their website with Java, which will be a cool interactive version. This customer does not have any Java programmers, but still requires any time they need to modify software behavior without having to make changes. What high requirements!
After some analysis of them, we found that the Command mode will play a very important role in this design. We will write a command object and let these command objects control the entire behavior of the software. Users will be able to parameterize these commands, sort them, and select the time and place of the command to run.
This solution works perfect, Command mode is the key to success. So here, we will not wait until you refactively use the Command mode. Instead, we have seen the need to use it in advance and use the Command mode from the beginning.
In another project, the system needs to run as a stand-alone application and web application. Builder model has played a huge role in this system. If there is no, I don't want to imagine how bloated designs we will put together. The role of Builder mode is to solve the problem of "multi-platform, multi-environment operation". So choose it correctly in the early stations.
Now, I have to declare: Even in the early days of design, it should still be implemented in accordance with their most primary look. Only when additional functions are needed later, the implementation of the pattern can be replaced or upgraded.
An example will make you clearer this.
The software that is controlled by the command object is implemented with multi-threaded code. Sometimes two threads use the same macro command to run a series of commands. But at first we didn't have a thread security problem that was macro command. So, when we start to meet the inexplicable problems caused by thread safety, we must re-consider our implementation. The problem is, should we take the time to construct a macro command? Or have there be a simpler way to solve this problem? We solve this problem with a simpler way and avoid over-design: provide a separate macro command instance for each thread. We can implement this solution within 30 seconds. Please compare this time with the time you need to design a thread security macro command.
This example describes how XP philosophy is simple in the case of using the model. Without this simplified driver, over-design solution - just like thread safety macro command - it is easy to appear.
Therefore, the association between simplification and patterns is important.
When a programmer needs to make design decisions, it is important that they should try to maintain design is simple, because simple design is usually more easily maintained and expanded more than huge and complex design. We already know that the refactor means keeping us on a simple way: it encourages us to gradually improve our design with small and easy steps and avoid over-design.
But what? Doesn't them help us keep simple?
Some people will say "no". They think that despite it, it is easy to cause complex design. They think that the model will increase the rapid object and lead to excessive dependence on object portfolios.
This view is due to the wrong understanding of the method of using the mode. Experienced model users will avoid complex design, rapid growth of objects and excessive object portfolios.
In fact, when using the mode, experienced mode users will make them easier. I will use an example to illustrate my point of view.
JUnit is a simple and useful Java test framework, its author is Kent Beck and Erich Gamma. This is a wonderful software, which is full of simple mode.
Recently, some people demanded that JUnit was degof, that is, remove the design pattern in junit to observe what JUnit without mode is like. This is a very interesting practice because it makes participants carefully consider when should be introduced in the system.
In order to describe what they have learned, we will degof in some extensions in the JUnit 2.1.
There is an abstract class called Testcase in JUnit, and all specific test classes are derived from it. The TestCase class does not provide any ways to run multiple runs, nor does it provide a method of running a test in your own thread. Erich and Kent are very elegant with Decorator mode to achieve repeatable testing and thread-based testing. But if the design team doesn't know Decorator mode? Let us see what they will develop and assessed their design.
This is the sample of Test Case in the JUnit Framework 1.0 (for simplification, we ignore the annotation and many methods):
Public Abstract Class Testcase Implements Test {
PRIVATE STRING FNAME;
Public Testcase (String Name) {
FNAME = Name;
}
Public void Run (TestResult Result) {
Result.startTest (this);
setup ();
Try {
Runtest ();
}
Catch (assertionfailederror e) {
Result.addfailure (this, e);
}
Catch (throwable e) {
Result.Adderror (this, e);
}
TEARDOWN ();
Result.endtest (this);
}
Public testResult run () {test result = defaultResult ();
Run (result);
Return Result;
}
Protected void runtest () throws throwable {
Method Runmethod = NULL;
Try {
Runmethod = getClass (). getMethod (FName, New Class [0]);
} catch (nosuchmethodexception e) {
E.FillInstackTrace ();
Throw e;
}
Try {
Runmethod.Invoke (this, new class [0]);
}
Catch (InvocationTargeTexception E) {
E.FillInstackTrace ();
throw E.GETTARGETEXCEPTION ();
}
Catch (ILLEGALACCESSEXCEE) {
E.FillInstackTrace ();
Throw e;
}
}
Public int counttestcases () {
Return 1;
}
}
The new demand requires that the test is repeated, or in their respective threads, or both.
Experienced programmers are typically performed when such new needs are encountered. But here, because the TestCase object will need to be able to run repeatedly in the same thread, or repeatedly run in the respective independent threads, the programmer knows: they need to consider more.
One implementation method is: add all the functions to the testcase itself. Many developers - especially developers who don't understand design patterns - will do so, not thinking that this will make them bloated. They must add features, so they add functions to any places you can add. The following code may be their implementation:
Public Abstract Class Testcase Implements Test {
PRIVATE STRING FNAME;
Private int frepeattimes;
Public Testcase (String Name) {
THIS (Name, 0);
}
Public Testcase (String Name, Int Repeattimes) {
FNAME = Name;
FrepeAtTimes = RepeAtTimes;
}
Public void Run (TestResult Result) {
For (INT i = 0; i Result.startTest (this); setup (); Try { Runtest (); } Catch (assertionfailederror e) { Result.addfailure (this, e); } Catch (throwable e) { Result.Adderror (this, e); } TEARDOWN (); Result.endtest (this); } } Public int counttestcases () { Return FrepeAttimes; } } Note that the Run (TestResult Result) is bigger. They also added additional structures to the TestCase class. So far, this is not something wrong. And, we can say: If this is all the things you must do, then use the Decorator mode is redundant. Now, what if you want to run every TestCase object in your own thread? There is also a possible implementation here: Public Abstract Class Testcase Implements Test {Private String FName Private int frepeattimes; PRIVATE BOOLEAN FTHREADED; Public Testcase (String Name) { THIS (Name, 0, False); } Public Testcase (String Name, Int Repeattimes) { THIS (Name, Repeattimes, False); } Public Testcase (String Name, Int Repeattimes, Boolean Thraded) { FNAME = Name; FrepeAtTimes = RepeAtTimes; fthreaded = threaded; } Public void Run (TestResult Result) { IF (fthreaded) { Final TestResult FinalResult = Result; Final Test THISTEST = THIS; Thread t = new thread () { Public void run () { For (INT i = 0; i FinalResult.StartTest (thistest); setup (); Try { Runtest (); } Catch (assertionfailederror e) { FinalResult.addfailure (THISTEST, E); } Catch (throwable e) { FinalResult.Adderror (THISTEST, E); } TEARDOWN (); FinalResult.endtest (thistest); } } } T.Start (); Result = finalResult; } else { For (INT i = 0; i Result.startTest (this); setup (); Try { Runtest (); } Catch (assertionfailederror e) { Result.addfailure (this, e); } Catch (throwable e) { Result.Adderror (this, e); } TEARDOWN (); Result.endtest (this); } } } Public int counttestcases () { Return FrepeAttimes; } } Oh, this seems to become worse. In order to support two new features, we now have three constructors, and the size of the Run (TestResult Result) expands. Even if all of these new codes, our programmers have not met these needs: We still can't repeat the test in your respective threads. For this purpose, we have to add more code. Forget it, I will let you go. Reconstruction can help this code reduces size. But just think slightly: What should we do if we receive a new demand? Now JUnit 3.1 supports four different TestCase modifiers, which can be easily combined to obtain the required features. At the same time, the implementation of JUnit is still simple - there is no confusing code. This design maintains a simple, lightweight, and user, and users only need to decorate the TestCase object when needed, and any combined order can be selected. Very clear, this is a model to help simplify the design. This example also illustrates how the lack of experience developers improve their design - if they know the reconstruction targets pointed out. Using mode to develop software is smart, but if you lack experience in use, it may also be dangerous. For this reason, I tried to promote the pattern learning group. These learning groups make people steadily and thus in the help of their companions. When people understand the pattern and use them in a trained manner - the most useful way - this trained way is the way of XP. Using XP-use mode to encourage developers to maintain design and reconstruct the pattern as needed. It encourages the key to use key mode in design. It encourages the problem with the pattern that can help solve the problem. Finally, it encourages the simple implementation of developers to write mode and then develop them as needed. In XP's scenario, mode is indeed more useful; and XP development is more likely to succeed when the mode is included. bibliography [Beck1 00] BECK, KENT. Email on extremeprogramming@egroups.com, January 2000. [Beck2 94] Patterns Generate Architectures, Kent Beck and Ralph Johnson, Ecoop 94 [GHJV1 95] Design Patterns: Elements of Reusable Object-Oriented Software, By Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Sino - translation: "Design Mode: Decisive Object Software", Li Yingjun and other translations. [GHJV2 95] Design Patterns: Elements of Reusable Object-Oriented Software, By Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Pages 353-354 Chinese transcripts: "Design mode: can be used for object-oriented software foundation", Li Yingjun Translation, Chapter 6. [Jeffries 99] Jeffries, Ron. Patterns and extreme programming. Portland Pattern repository. December, 1999 [Kerth 99] KERTH, NORM. Conversation, Circa March, 1999. [Kerievsky 96] Kerievsky, Joshua. Don't distinguish Between Classes and interfaces. Portland Pattern Repository. Circa 1996
