Refactoring Patterns: Seventh Part
content:
Refactoring Application Refactoring and Name Reference About the author
related information:
Other parts of this series
Refactoring occasion and basic naming rules Stone 1 (shiyiying@hotmail.com) Zhejiang University Lingfeng Technology Development Company Director December 2001
Although refactoring can almost operate at any time, in accordance with our principles about two hats, under certain occasions, refactoring intervention is more practical, meaningful and effective.
In addition, before I entered Refactoring Practice, I put Kent Beck and Martin Fowler to our advice and suggestions here. These content, especially Code Smell and naming rules, not only have a strong sense of practice. At the same time, they also throw us more thinking about the principles of many OO design and coding.
Refactoring Application Increase Features If your code does not need to add new features, then you have little need to reactoring him. The increase in function is the most common cause of Refactoring. Usually, the first goal of Refactoring is to make the code easier to understand. Refactoring can not only make it difficult to understand, but he can also make you understand its understanding, interact with your code. Understand, new features is easy to join. Another reason is that the structure of the original code is difficult to expand directly, it may be because a class and another class is too tight, or he uses a lot of case statement, or some duplicate code makes you feel you add to you. The code will make the structure worse. All in all, directly adding new features is not too convenient. At this time, you need refactoring, so that the old code will make the new code to add more convenient and fast in the event of an old Test Case. Reuse reuse can be said to be a special case of increasing functions. Because this is the most important method of OO increase function. But there are some differences here. If your code is a framework, you must focus on the reuse of the frame when you hand over the code to others. For example, you want to add a layer of Facade on the frame, this time you may need a refactoring some internal classes, making this facade structure easier to join. The framework refactoring may need to be a feedback process. Because the framework is stable, it may exist for a long time. Generally, you will not add function directly to this framework. At this time, the accumulation of different applications to the framework experience can make your Refactoring have more clear goals, more abstractions. There are a lot of reasons for correcting bug bug. It may be that your problem is not enough, it may be that the code's code is too chaotic. When your code structure is not very clear, BUG is often hidden in the code, making it difficult to find. Applying refactoring allows the code structure structure to be clearer, and the bug is automatically surfaced. The goals and processes pursued by Refactoring often make the bug of the code nowhere. Eric E. ALEN in the bug pattern in the IBM DeveloperWorks is the Copy-And-Paste method causes the code to repeat, thereby generating an example of bug. This Rogue Title Pattern is a very common bug example. When you fix a bug in the program, the result you find that the program run is that the bug that you have revised is still being born. The reason is that the programmer copies a code in the past when implementing a function, and a little modification is a new function. You have modified a place, but I forgot another place. Refactoring strives to exclude duplicate code, if there is such a bug, after refactoring, a modification can correct all the questions. The Code Review Review allows expert knowledge to spread throughout the development team. They can help more people understand a large number of problems. They also have a good help to write a clear code. As the saying goes, the three stinky leisses will have a Zhuge Liang, and Review also makes you accept more goodbye and ideas, so that your design and code are more reasonable. According to Martin Fowler, I use refactoring as my main REVIEW method. I have more opportunities to do such a Code Review, and when the programmer finds a difficult bug, or when they feel that their ideas can't go, they usually ask me.
My method is usually asking a few simple questions, then find their code directly, performing refactoring, in this process, I am always refactoring, while explaining my intentions and programmakers. Surprisingly, once I do this, programmers often find problems in my refactoring process. Since the result of Refactoring is very specific, I can easily tell the programmer some examples that can be implemented directly, which is great for improving programmers' programming capabilities. The taste Kent Beck's "Code Smell" may be the most people 's famous sayings of the OO community. Martin Fowler and Kent Beck specifically completed the "refactoring" one of the chapters called "Bad Smells In Code". Although the study of Refactoring involves the structure of the formally detecting code, such as a dedicated duplicate code monitoring tool. But these studies are still in the early age. What's more, many of the structures of the code are not able to solve with simple digital statistics and abstract speech trees. Code Smell is a high level of programmer's feeling of code. When you can smell such a taste, you can "smell" the code structure when you don't involve the specific problem to solve. . The code of the code listed in Kent Beck and Martin Fowler is:
Duplicated Code code is almost the most common odor. He is also one of the main goals of Refactoring. Code repetitions are often derived from Copy-and-Paste programming style. Compared with him is an important symbol of a good system (see my duplicated code). Long Method It is a traditional structured "of the whole". A method should have self-independent intentions, do not put a few intentions together, and I have a detailed description in my "Class and Long Method". Large Class Class is that you have given too much responsibility to a class. The rules here are One Class One Responsibility. See my "big class and long method". DIVERGENT CHANGE is different from the content change rate in a class. Some states have changed one hour, and some will change once a few months; some states have changed because of this reason, while others changed once. Object-oriented abstraction is to isolate relatively unchanged and relative changes. Separate the side and the other aspect of the problem. This makes these relatively unchanged reuse. Every aspect of the problem changes can be reused separately. This coexistence coexistence makes it very difficult to reuse. SHOTGUN SURGERY This is just the opposite of it. Changes to the system a place involve correlation changes in many other places. Status and behavior of these variations and changes in content should usually be placed in the same class. The purpose of the Feature Envy object is to encapsulate and closely related to these states. If a class method is frequently calculated using a GET method to access the status of other classes, then you have to consider moving behavior to that class involving the number of status. Data CLUMPS Some data is usually playing like a child: together in many class member variables, together in many ways, and these data should be independently forming objects. Primitive Obsession Object-Oriented Novice is usually used to using several original type of data to represent a concept. For example, for the scope, they will use two numbers. For Money, they will use a floating point number. Because you don't use objects to express the concepts in the problem, this makes the code change difficult to understand, and the difficulty of solving the problem is greatly increased. A good habit is that the expansion language can provide the original type, use small objects to represent scope, amount, conversion rate, postal code, etc. The switch statement based on the Switch Statement is the enemy of OO, and you should turn him into a subclass, State or Strategy. Parallel Inheritance Hierarchies parallel inheritance level is the special situation of Shotgun Surgery. Because when you change a certain class in a level, you must change another level of parallel. Lazy Class is a categorically categorous class. The maintenance of classes requires additional overhead. If a class takes too little responsibility, it should be eliminated. Speculation generality A class implements the features and versatility of never use. Usually such a class or method unique user is Test Case. Don't hesitate, delete it. Temporary Field A object's properties may only be meaningful in some cases. Such a code will be difficult to understand. Establish an object to hold such orphan attributes, move the behavior that only to him to this class. The most common is a specific algorithm that requires some variables that only the algorithm is only available. The Message Chain message chain occurs when a customer requests another object to an object, and then the customer requires another object to this another object, and then request another object to this another object, so. At this time, you need to hide the dispatch. One of the basic features of the Middleman object is package, and you often use it to achieve encapsulation. But this step can't be too far, if you find a large half of the way a class interface is assigned, you may need to remove this middleman. Inappriate intimacy certain classes are too close, they spend too much time to go to the private parts of others.
For humans, we may not be too false, but we should make our classes strictly abide by abstinence. Alternative classes with diffracity Methods Methods Make the same thing have different function signatures, unanimously moved to the class level until the agreement is consistent. INCOMPLETE LIBRARY CLASS is very difficult to build a good class library. Our large program work is based on class library. However, such a broad and univautable target puts a harsh requirement for the library builders. The library is not universal. Sometimes we will find that the library class cannot achieve the features we need. It is very difficult to modify the library class directly. At this time, you need to use a variety of means for refactoring. Data Class objects include status and behavior. If a class is only a state, there is no behavior, then there is certainly something wrong. The REFUSED BEQUEST superclass has passed a lot of behavior and status, while subclasses are only used in a small part. This usually means having a problem with your class level. Comments often feel that you have to write a lot of comments indicating that your code is difficult to understand. If this feeling is too much, you need a refactoring. Refactoring and naming refactoring makes one of the most effective and common means of making code more easily and common means to give classes, methods, and attributes a right name. Many companies and individuals have compiled a large number of code naming specifications. If these specifications are too cumbersome, it will not be executed. Have a good naming rule is a good thing, but it is not always the case. Most importantly, in the entire project development team, the consistent naming rules must be maintained, may not be the best in the world, but it is the best for the project. The following is some of the effective naming principles in Refactoring: Class name Kent Beck proposes most of the rules. Kent Beck's "SmallTalk Best Practice Pattern" is all books I have read so far, the most inquiry of my aesthetic views - profound knowledge and brushworks of spring and autumn. Simple superclass name - the naming of design purposes is always subject to various factors. You want to make the name as short as possible, easy to enter, format, and easy to say. At the same time, you also want the name to contain more information as much as possible so that the reader can understand the actual content included in the name faster. You may take some names that are familiar with people so that you can pass more common experiences in your name. At the same time, you also want the name as soon as possible, others' code naming will not be repeated with you. The first rule given by Kent Beck is not abbreviated. Abbreviations are considered for the considering of the enumeration (10-100 times within 20 years) (10-10000 times in 20 years). It takes two steps to understand the narration. The first step is to understand the words of these abbreviations, and the second step takes the meaning representative of these words. Named a large-level root class is a major decision. In the next 20 years, people may constantly use the name you give. You have to do not make mistakes. People usually add a variety of modifications when naming super categories, computer scientific significance, giving people a deep impression, but eventually, meaningless words, such as Object, Thing, Component, Part, Manager, Entity or Item. You are creating a vocabulary instead of writing a program. Temporarily do a poet. Simple, energetic, easy memory is far more effective than saying all content. Rules: Name A Superclass with a single word what conveys ITS Purpose in the design. (Named super class with a word, convey its design purposes), and good examples include: Number, Collection, Magnitude, Model full name subclass name - a way to distinguish between the same name is to give a unique name. The only name allows you to use the shortest information to express the most information. This is correct for general terms.
Array is a subclass of Collection because most people know what "Array" means. However, in most cases, the hierarchy of the inheritance is important for understanding your code, especially a subclass concept is superclatrifugated, and the situation is achieved at the same time. You need to pass two parts: 1. How new classes are the same, and 2. How new classes are different, you can borrow superclatrun names. This is not necessarily a direct subclass and parental relationship, and there is a distance in the level. To express the expression, you need a word to emphasize why the new category is not a reasonable reason. So, there is rule: name subclasses in your hierarchies by prepending on an adjective to the superclass name. (Add the subclass in your hierarchy before the superclass name.) For example: Biginteger is an integer that can express great numbers. Method naming - revealing why good code has a lot of simple methods, code may only have one line, such as: Class Paragrapheditor. . . .
Public void highlight (all) {
Reverse (all);
} This highlight is just assigned to Reverse, why still needs? The key is Communication. Because there is this method, you can use highlight to speak with highlight. I want to brighten a zone, I will highlight it. Of course you can use Reverse directly, the result is the same. But all calling code revealed the implementation - "I highlight it by reversing a rectangle." The code should be disclosed, and it is more convenient to be repaired more convenient. If you want a paragrapheditor to brighten with the color, just inherit Paragrapheditor and override you. So: Communicate What Is To Be Done Rather Than How It Is To Be Done. (Communicate what you want (interface) instead of you ") instance (temporary) variable naming - hints the information of any instance variable conveyed by two parts:
What is its purpose? How do it been used? The purpose of a variable or that it is very important to the reader because it can correctly guide the reader's attention. Generally, you have a purpose in your head when you read the code. If you understand the role of the variable, this role is not related to your purpose, then you can directly skip the independent code of using the variable. If the role of this variable is found to be related to your purpose, then you will immediately reduce your reading range - those related codes that reference this variable. How to use and send it to what message is usually its "type". The type of understanding is not important. However, for instance variables, you can understand that the role of this variable is its name. If there is two instance variables in a point called int1, int2 is not x, y, then which one is a horizontal coordinate, which one is before, you may have to have a bunch of code. What's more, you have to read a lot of code related to it. The type of variable is easy to declare from it, and the news passed to it. So: Name Instance Variable for the Role The Play In The Computation. Make the name plural if The Variable Will Hold A Collection. (Name the role assumed by the example variable in the calculation. If the variable holds a collection, use the plural.) Reference Bibliography
Martin Fowler: "Refactoring: Improving the design of existing Code" Kent Beck: "Extreme Programming Explained" Kent Beck: "Smalltalk Best Practice Pattern" William C. Wake: "Extreme Programming Explored" Jeff Langr: "Evolution of Test and Code Via Test-First Design "Robert C. Martin:" An Extreme Programming Episode "Don Robert, John Brant and Ralph Johnson:" A Refactoring Tool for Smalltalk "Jrefactory: jrefactory.Sourceforge.net Gamma, Junit: http: //members.pingnet .ch / gamma / junit.htm Refactoring Browser: http://chip.cs.uiuc.edu/users/brant/Refactory/ GOF: "Design Patterns: Elements of Reusable Object Oriented Software" MartinFowler: "UML distilled" Braint Foote and Joseph Yoder: "Big Ball of Mud" William Opdyke Ph.D. Thesis: "Refactoring Object-Oriented Frameworks" Braint Foote and William Opdyke: "Life Cycle and Refactoring Patterns that Support Evolution and Reuse" Mel O Cinneide: Ph.D "Automated Application of Design Patterns: a refactoring approach" DONALD BRADLEY ROBERTS: ph.d.:"practi cal Analysis for Refactoring "C2: www.c2.com Eric Gamma, Kent Beck: Junit: http://www.junit.org Lance Tokuda:" Evolving Object-Oriented Designs with Refactoring "Michael Hunger:" Refactoring: Benefits and Disadvantages "TOMCAT BOOK Shiyiying: Code Smell serials William F. Opdyke, Object-Oriented Refactoring, Legacy Constraints and Reuse Stephen R.Schach:" Classical and Object-Oriented Software Engineering "Christopher Alexander:" The Timeless Way of Building "a stone About the author He is currently the technical director of Zhejiang University Lingfeng Technology Development. 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.
