The pattern is an object-oriented cornerstone, and the test priority programming method and the big knife are refactoring is the cornerstone of evolution. In order to avoid excessive design or insufficient design, we need to learn how to adapt the model to new, progressive software development rhythm.
--Joshua Kerievsky
The greatness of software models is that they have passed many useful design ideas. So, if you learn a lot of patterns, you can become a quite excellent software designer, right? When I learned, after dozens of patterns, I thought I thought. These patterns help me develop a more flexible framework, built a more robust, more scalable software system. However, after two years, I found that the understanding of the model and use often let me fall into the situation of over-design.
After the design skills increased a grade, I found that I started using the model in another way: refactoring to get the pattern, not in the previous design, but also introduced them into the code. This new way comes from the design practice of extreme programming (XP), which makes me not much, just right.
What is over-design?
When you get the code more complicated than need, you are still flexible, you are over-design. Some people do this because they believe that they know the future needs of the system. They think: It is best to make the design flexible today, complicated, so it can adapt to tomorrow's needs. It sounds beautiful if you can do not know if you know.
However, if your prophecy is wrong, you are a waste of precious time and money. It takes a few days and even weeks to give the design to increase unnecessary flexibility, this situation is very common - the result, giving the system addresses, and less time to troubleshoot the error.
If you write code according to the pre-idea, the expected need does not appear, what should I do? You won't delete it because it will be more troublesome, or you also want to use these things in the future. No matter what reason, anyway, these excessive flexible, more complex code, more and more other programmers in the team have to work on more and more, more and more complex code work.
In order to compensate for all, people decided to divide the system into independent small pieces, each responsible for one. This seems to make their work easily, but there is a side effect: everyone will write code according to their own ideas, very few people who have already done their own work, so there are many repetitive code. .
Over-designs will affect productivity, because when others have taken such a design, he has to spend some time to learn about the designs of the design, and then expand or maintain it comfortably.
Over-design always happened quietly, many designers and programmers didn't even realize that they are over-design. When their company discovered that the team productivity fell, few people know that the role they played over.
The programmers will be over-design, perhaps the main reason is that they don't want to be trapped by bad design. A bad design is often too close to the code, so it is difficult to improve. I have also encountered this kind of thing, so I prefer to use the model to pre-design.
Mode, Wanling
When I started learning mode for the first time, they show me a flexible, exquisite and elegant object-oriented design method, which is exactly what I want to master. After learning the mode systematically, I will start using them to improve the previous system and construct the system. Since I know what the pattern can bring, I feel that I am willing to be a correct way.
However, over time, the power of the pattern makes me invisible to the simpler writing code. As long as there are two or three different calculation methods, I immediately ran to implement the Strategy mode, but in fact, a simple conditional expression is simpler and easier, and more practical.
There is a thing that makes me disclaimed the model's focus. At that time, I wrote a program with another person, and we have written such a class: it implements the Java's TreeModel interface to display a pattern of specific objects in a tree window control. Our code is able to work, but the tree control will call the toString () method of each displayed object at the time of display, but this method does not return the information we want. We can't modify the toString () method, because the other parts of the system depends on this method. So we started thinking. The habit is caused, I immediately thought of the pattern. First, in my mind is Decorator mode, so I propose to encapsulate the object to be displayed with Decorator mode, and then reload the toString () method of the package object. Unfortunately, my partner's answer makes me shocking: "Killing chicken is used with a cow knife?" He created a class named NodeDisplay, which received an instance of the class to be displayed. The NodeDisplay class is easy to write because all of its code is less than 10 lines. And my Decorator mode is at least 50 line code. It is necessary to call the object you need to display by many delegates. As such experience, let me know: I can't think about the mode more than the mode, and I must return to the short-dry code. So, once a choice stood in front of me: In order to become a better software designer, I spent a lot of effort to learn the model; but now, in order to increase a level, I can't rely on them.
Want speed is not reached
To improve a grade, you must also learn to avoid insufficient design. Compared with over-design, the shortest design is often much more common. If we just want to add more and more features to the system, don't pay attention to improving design, it is likely to make an incorrect design. Many programmers are doing so - I'm trying to do so. You only make the code can run, then go to the next task, and never come back to improve the current written code. Of course, you hope that you often come back to maintain your own code, but either because you are too busy, or because the manager and the customer are tight, you still have no time.
This is the disarity of the software, which will make your software development rhythm into "fast, slow, slower", just like this:
1. You quickly released the system's version 1.0, but the code quality is very.
2. You want to post version 2.0, but the code is slowed down.
3. When you want to release the future version, because the code is getting more and more, your speed is getting slower, until the customer and the boss lose confidence in this system.
In our industry, this kind of thing is the company, it will greatly reduce the competitiveness of the company. Fortunately, there is another good way.
Socrates development
Test priority programming, big knife rebuild, these two practices from extreme programming thoroughly changed the way I developed software. I found that these two practices helped me and helped the entire company. We will neither design, nor is it insufficient, and a lot of time to meet our needs: a good system, delivered on time.
Test priority programming methods turn program design into Socate question and answer: Write test is to mention a question to your system, then you should write code to answer this question. Repeat this question and answer process until you get the required system. Such methods greatly increase the effectiveness of the encoding. This programming rhythm makes me feel refreshing: No need to consider every fine branch of the system again. Test the priority programming method allows you to implement the main functions first, and then improve it as needed to achieve the desired flexibility.
The big knife is a part of this progressive design process. Reconstructing is "Keeping Code Conversion", or in accordance with the definition of Martin Fowler, the reconstruction is "modify it without changing the external behavior of the code, to improve the internal structure of the code, make it easier to understand Or modify. When Socrates should talk about a truth, he always uses the question and answer form. When the subject answered an answer, Socrate will ask more questions. Through these problems, he helps the people who have nothing to do with insignificant things, and clarify the thoughts of chaos, and consolidate the knowledge learned. This is the role of the reconstructed play. When you are reconstructed, you constantly dissect your code, remove the repetition, making it getting clearer and clearer, more and more simple.
Refactoring is also a skill. You can't make a schedule for improved system design, re-configured for the specified time; you must refactor when any need. Reconstruction can improve your code quality, so that you can maintain a healthy development rhythm. "System Reconstruction: Improved Existing Design" by Martin Fowler et al. [1] The book records a lot of reconfiguration methods, each of which is pointed out in a common improvement requirement and the improvement step.
Why do you have to get the pattern by reconstructing?
In many different projects, I observed the way they were reconstructed with colleagues. While many reconstruction methods recorded in the book of Fowler, we still find models can also help us improve design. At these times, we have to get patterns through reconstruction, avoiding excessive flexibility or unnecessary complexity.
The motivation of "Refactoring Getting Mode" and "Refinitely Reconstructing" is the same: reducing or removing duplicate, simplifying design, making code better to express their intentions.
However, the reconstruction of the mode is not a mode in the book. For example, let's take a look at the "intentions" and "Applicability" written on the book, and then look at Erich Gamma and Kent Beck by reconstructing the Decorator mode by reconstructing the Decorator mode in JUnit.
Decorator mode: [2]
Dynamically add some additional responsibilities to an object. In terms of increased function, Decorator mode is more flexible compared to generated subclasses.
Application of Decorator Mode:
Use Decorator mode in the following cases
l Add responsibility to a single object in a dynamic, transparent manner without affecting other objects.
l Handle those responsibilities that can withdraw.
l When the method of generating subclasses cannot be expanded. One case is that there may be a large number of independent extensions, to support each combination, which will generate a large number of subclasses, resulting in explosive growth. Another situation may be because class definitions are hidden, or class definitions cannot be used to generate a subclass.
Get the motivation of Decorator mode by reconstructing Decorator mode by reconstructing
Why is it to reconstruct Decorator mode? Erich remembers the following reasons:
"Some people have added TestSetup classes and as a subclass of TestSuite. After adding REATEATEDTESTCASE and ActiveTestCase, we find that we can reduce the duplication through the Decorator mode." [3]
Have you seen it? Refactoring the motivation of Decorator mode (reducing duplicate code) and Decorator mode "intent" and "applicability" (as a dynamic alternative to subclass) have almost no relationships. I also found similar situations for other modes. Please see the example below:
mode
Interest (GOF) [4]
Reconstruction
Builder
Separation of a complex object is separated from its representation, making the same build process can create different representations.
Simplified code
remove duplicates
Reduce creation error
Factory Method
Define an interface for creating an object, which allows the subclass to decide which class is instantiated. Factory Method delays a class of instantiation to their subclasses. remove duplicates
Intention
Template Method
Define the skeleton of an algorithm in an operation to delay some steps into the subclass. Template Method allows subclasses to redefine certain specific steps of the algorithm without changing the structure of an algorithm.
remove duplicates
Based on these observations, I began to record some "reconstructed results" methods, and they use them to describe the meaning of improving design. In this process, I used the reconstruction from the real project as an example, and only this can accurately describe the use of the system constraints and patterns.
I have a continuation of "Refactoring Get Mode" is the continuation of Martin Fowler. In his recording, there are some examples of reconstruction to get the model:
· Form Template Method (345)
· Introduce NULL OBJECT (260)
· Replace Constructor with factory method (304)
Replace Type Code with State / Strategy (227)
· DuPlicate Observed Data (189)
In addition, Fowler also mentioned:
There is a natural connection between modes and reconstruction. The mode is the destination you want to arrive; the reconstruction is from another place. [5]
This is also in good agreement with the four authors of "design model":
Our design model records many reconstructed design structures. ...... Design model provides a goal for your reconstruction. [6]
Gradual design
Today, in the model - "Reconstructive Design Structure" - After familiarity, I finally understand: understand the reason for the modification of the model, more valuable than the details of the final result or achieve this result. .
If you want to be a better software designer, then the development process of learning well software is more valuable than learning these design itself, because the process of design and development is the wisdom hiding. The final design structure that the final design can help you, but if you don't know how it develops, you will like it to use it, causing your project over-design.
Now, our software design literature is overcomes well in good solutions, and does not pay much attention to the development of these solutions. We need to change this situation. Reconstructing information can help us better understand a good design because it reveals the evolution process of these programs.
For most modes, we must treat this: observe mode in the reconstructed scene, not only to deepe mode as a reused software unit. This may be my collection, preparing the original intention of this series of articles.
By learning progressive design methods, you can become a better software designer and reduce the chance of over-design and insufficient design. Test the priority programming method and the rebuild of the big knife are the key to progressive design. Learn to get the model by reconstruction, you will find your ability and you can make excellent design.
Writing goal
To date, I have written more than more than ten articles on refactoring, and there are other subjects. Writing this series of articles is to help you learn how
l The mode is obtained by reconstructing the pattern when appropriate, and the mode is abandoned when there is a simpler scheme.
l Use mode to express your intentions
l Understand and continue to learn a lot of modes
l Understand how to implement patterns in a simple way and complicated manner
l Use the mode to make the code more concise, clearer
l gradual design
I am using the format used here and Martin is almost exactly the same as the format used in System Reconstruction. In addition, I added the following elements:
l Communication, repeat and simplification
l Adding a comparable step in the "Process", corresponds to the steps in the Example.
My series will continue to be a long time, so welcome to me. Please send your thoughts, comments, or questions to Joshua@industrialLogic.com [7]. This series will be disclosed on the Internet, and the address is http://industrialogic.com/xp/refactoring/[8]. I also opened a mailing list (refactoring@yahogroup.com [9]) used to discuss the Ide, the Ide, which supports the reconstruction, design mode, and supporting automation.
[1] Translation: This book name is based on Mr. Houjie, supplemented by the word habit of continent. The original title is refactoring: Improving The Design of Existing Code, Addison-Wesley 1999 published.
[2] Translation: Eric Gamma is waiting, Li Yingjun et al, "Design Mode", Machinery Industry Press, published in 2000, page 115.
[3] Translation: This paragraph is from Eric Gamma and the author's private letters.
[4] Translation: The "intention" here all quoted the "design model" of Li Yingjun et al.
[5] Translation: This sentence comes from "System Reconstruction", which is my self-proposed translation.
[6] Translation: Troubled from "Design Mode", page 234.
[7] Translation: This is the author's mailbox. If you have the idea of Chinese translation, or if you don't want to communicate with the author in English, please tell me: gigix@umlchina.com
[8] Translation: This is the address of the original text. Chinese translation is disclosed on my homepage.
[9] Demand: There is currently no corresponding Chinese mailing list, you can discuss related issues on an existing mailing list (DPE_CN@yahoogroups.com).
