Refactoring Patterns: Section 6
content:
Simplified design design
related information:
Other parts of this series
Refactoring and Software Design Shiyi (Shiyiying@hotmail.com) Zhejiang University Lingfeng Technology Development Company Director December 2001
Refactoring is an important design auxiliary tool. In particular, he can make the traditional UP-Front design easier, or improve the design of existing software. This article describes the relationship between the design of the design and the most eye-catching design model in the application of the Refactoring environment.
What is the design should be simple? Traditional software methods are biased to the disposable Upfront design, we know this is difficult. Software methodology designers usually like to use architecture. They said that if you want to build a building, you never start truly construction before you draw all the construction drawings and architectural norms. I like this metaphor, because the development of architecture has experienced thousands of years or may be 10,000 years, and the software industry is only 5, 60 years, we need to learn a lot from the building. Just as the presenter of the pattern language, the famous architecture, Christopher Alexander, gave the design pattern. However, if we just learn something from architecture, I am afraid still far enough. I still don't know which building can change, or which big shopping mall is discovered that the escalator is not very suitable, it is free to move to a more suitable place (I have a big supermarket near my supermarket really let I thought of this). It may be that it is still possible to partially achieve such a purpose, but it is definitely a high cost. But if we go to construct a business application system, we must prepare the company to change our software. The core of the software is variable. This change is not only the changes in demand, but also people understand changes, and the product of this person's activities must have changed. The development methodology of increment iteration is a response to software changes. However, as we mentioned earlier, incremental iterative models may make a more complex requirement for the design of the system than traditional Waterfall. You need to expect all possible situations before, then you can guarantee that you can increase, but it iterates. This two difficulties are derived from a basic assumption: the most important way to reduce software cost is to reduce the cost of rework and its possibilities. Traditional software issued a law to learn, if I can freeze the demand early, then the possibility and cost of the design is, if my design can freeze as soon as possible, then the possibility and cost of my modification is smaller. . It is necessary to freeze the design early, it must be very detailed and complicated. I called this idea to "change phobia", not only because of the most difficult thing to study (more simple frame boxes), but also because we don't have enough experience to adapt to changes, more importantly, No era is faster than today. Now we want to ask questions from another perspective: Will we reduce the cost of software by adding rework methods? This method seems to be self-contradictory. But Kent Beck said: The Key Is That Risk Is Money Just As Much As Time is Money. Since the system is changing, then you can't affirm that things design today will be used in the future. The cost you need to wait for the design is high, because no one can start working before your design is completed. The design is not independent. Others want to use your design, he must understand your design. If you are very complicated today, then you have added all overheads starting today, more things need to be checked and tested, more things need to understand, more things need to explain. More importantly, you can't estimate the cost of tomorrow. You must estimate what will happen in the future, usually you can't do this accurately. Therefore, let the design simple, we can make the system more close to the demand through the continuous incremental modification design, just like we drive, do some small adjustments each time, finally reach the destination. What is a simple design? To make your design, do we mean that we can freely fix and write, and then modify it.
But it doesn't mean that it is random, of course, does not mean stupid. Just like I pointed out in Duplicate Code, Once and Only ONCE is usually the simplest code because it has no repetition, and each class has its own simple responsibility, each method has its own simple intention. Simple design is the most important feature is easy to adapt to change. In order to achieve this, simple design should:
It can be simply understood. This depends on your code of code. Only understandable, the following simplicity can be achieved. It can be simply modified and expanded. OE system often changes or increase system behavior through incremental methods, so That is to be simply reuse, this requires us not to repeat the code. There are minimum number of classes. If you want to understand the system, each class should correspond to every important concept of the problem that needs to be resolved, if artificial joins many The meaningless class or too much is unable to correspond to a class, the system will not understand the minimum number of methods. Each method should have his independence, if you don't have the name of the mind, then the system will be difficult to understand If you have seen Kent Beck and other Agile Alliance authors, or you have seen my duplicate code and long method, you may feel contradictory 2 and 3, 4. Because you want to reach 2, you must have Many small and well-dried methods, while 3, 4 requires you to have the least classes and methods. To understand the critical key between them is, how do you decide to need a new category or need a new method. In progress Refactoring If you think that a part of the system has an independent concept of the concept of corresponding problem, then you should use the extract class to form a new class without hesitation. Conversely, a certain class cannot have its independent application meaning, or There are too many class data without behavior. At this time, you should consider this class should be deleted. Of course, some exceptions (such as Method Object), if a code snippet can have independent behavior, then regardless of its Size, it may be a simple expression, there should be an independent method, but if there is no such clear intention, more code can be in a method. Obviously, simple design is not as simple as we think. It can not consider the problem after the following solve problems, is simple, as an important aesthetic standard. It is not easy to achieve. We can not achieve this requirement, it may be unreasonable, there may be repetitions The code, the assignment of possible behavior needs to be adjusted, to be simple, you must refactoring your code, make the design more reasonable. How does Refactoring support simple Upfront design? Start, you can make a simple design, perhaps a class, 2, 3 ways, you write Test Case, implement the code, let Test Case pass. In the process of achieving this class, you find that 2, 3 methods are too long, there will be many duplicate code between them, so you do Refactoring, you use the extract method to make the way more reveal. Then, you solve another problem, you write another Test Case, there is no big relationship with a class above, or you can find that this class has attached some features on the previous class. At this time, you will find that it is more difficult to modify the previous classes, you review a class for a class, let it easily join. If the new feature is added, found that one class in front contains two application concepts, you may need to reconstruct this class and split it into two classes. You carry refactoring so that all Test Cast can be tested. You then choose a requirement, add new Test Case, and then implement it. At this time, you found that this class and the original class have a lot of similar places, you may need to further abstract these two classes, form a new superclass through Refactoring. . . Over time, more and more demand is realized, the system becomes bigger and bigger, one day, you find that the system has some variables, you think it is necessary to modify a part of the system. At this time, you and your colleagues may need to temporarily pick up the hat. You may need more discussions, communicate, and use any meaningful way to enhance the effects of exchanges, whiteboard, CRC, and then conduct refactoring. Kent Beck pointed out that some big refactoring may not be completed one day. It may take a few days or even a month. However, you also need to continue to complete the needs of users.
The method taken at this time is the increase in increase in small steps. When you implement new needs, when you write new Test Case, you may see a chance to make your code further before the big goal. Using this method, each time your work may be moving a variable or a method. However, as new functions further add, this opportunity continues to appear. In the end, a big goal will become a small job. At this time, you have already taken it to the streak, and it will be completed in a few minutes. Refactoring's way of working can greatly reduce Upfront's design, which makes your design into a necessary product, which is more accurately reflected in order to better join new needs. Bible. At the same time, it makes the design more reasonable as you have further deeply and more about the problem, and as you have become smart as you have the mastery of the new technology, this is an evolutionary design method. Design mode Simple design requirements Refactoring support for simple design seems to make design patterns. If I only need to write a simple Test Cast, implement, refactoring, increase Test Cast, implement, refactoring. Does this mean that design patterns are meaningless? For design patterns and refactoring, and related AGILE Alliance Methods to I have a deep impression. One aspect, like Martin Fowler pointed out that Agile Method's advocate is often the leader of the model community. On the other hand, if you carefully understand the Agile Declaration, you will find that they attach great attention to people. In the process of I organized group trial XP, XP has a high demand for its participants. We have seen that simple design is not a stupid design. In contrast, they are extremely smart design. To achieve a simple design, you must have a wealth of knowledge. Here is that simple design advocates that you don't think too much about the concrete needs itself, but it does need to consider the structure of code and design. I have already said that if your design structure is completely unscrupulous, then refactoring is not powerful. The design pattern is an important summary for object-oriented societies. In fact, they are also the best interpretation of simple design. Because, good design patterns are the simplest, most easily reused design structure that can be found in solving problems. On the other hand, the use of widely known design patterns also makes your code easier for people, accept, greatly improves the efficiency, width and depth of communication. In this sense, Refactoring not only does not exclude design patterns, but also promotes learning, discovery, and verification of design patterns, as well as wider applications. Agile has also been fully reflected in this regard of the quality of programmers. Once the team members have the ability to skilled design patterns, your design may be a sentence: use xxx mode. (In the EOSP2P project I led, this mode is half-state / half strategic mode. When I said this mode, we found that the entire group no longer needs Upfront design, we build, then refactoring. Of course, like the Factory Method mode is almost Each system should be used. There is also a subsequent proxy mode that makes the design so easy). However, in the process of applying design patterns, you must remember the principle of simplicity. The best application method of design mode is to start from simple start, as long as you can solve the problem, grab the core of this model, then the model is good structure to ensure that your Refactoring is based on a solid foundation.
So, in order to make Refactoring better, you need more learning models, because design patterns are not only a good design, but also the goal of refactoring. Refactoring's target refactoring sometimes loses the goal, you may generate a loopful refactoring, or you can't determine that the result of Refactoring is better than the structure of the program. The design model as one of the most important contributions of the OO community can provide a clear goal for Refactoring. This issue is mentioned in the multi-story papers about the Ralph Johnson. State, Strategy, Visitor and other modes are clearly pointed out in "Refactoring" in Martin Fowler. More in-step, design patterns are not only Refactoring's goals, but also provide a global guidelines for it seems some scattered behaviors. Christopher Alexander is defined in the "The Timeless Way of Building" as follows: Each Pattern Is A Three-Part Rule, Which Expression A Relation Between a Certain Context, A Problem, And A Solution. Many people are in software His definition has made modifications and expansions, but these three parts are constant. Put this definition in our software context, design model has two important features: design mode is higher than the code layer, he is not a good coding style, or some programming habit; design mode is not a purely theoretical system Structure or analysis method, it is something that can be actually operated. The Three Rules proposed by the pattern field said that you must propose three actual application examples to get the condition of the design mode. Because of this, many people call the design pattern as Micro-Architecture. Obviously, due to its operability, it can be achieved by refactoring. At the same time, he can be used to guide Refactoring and act as Refactoring targets.
About the author Shi Yizhen, is currently the technical director of Zhejiang University Lingfeng Technology Development Company. Many years engaged in OO system analysis, design. The main research direction is refactoring and analysis mode. You can contact me via shiyiying@hotmail.com.
