"Refactoring: Improving the design of existing code" reading notes

?? If a person has not heard of the "refactoring" book, then he must not dare to say that he is a programmer; If a person has not read the "refactoring" book, it is hard to imagine that he will be a good programmer. This book is one of the three books that many companies require Java programmers to read (the other two books are "Java Programming ideas" and "effective Java"), which are irrelevant to the programming language that programmers can benefit from.
?? What is refactoring? Refactoring is an adjustment to the internal structure of software, which aims to improve its comprehension and reduce the cost of modification without changing the observable behavior of software. Refactoring is a small step to modify the program, in this process can easily find errors in the program. The time to refactor can be when you add a feature, you can fix the error, or when you review the code. The goal of refactoring is to make code easy to read, all logic to be specified in a unique location, new changes that do not compromise existing behavior, and as simple as possible to express logic.
?? This book is my personal favorite third chapter-"Bad Taste of code" because I like to think about the bad taste in my code after writing the code, and then think about how to refactor the code. The author of the book is a world-class software development master Martin Fowler, also known as the "Godfather" of software development, and he is also one of the founders of agile Development. Martin Fowler has written a number of great books, including the Enterprise Application architecture model, domain Specific language, NoSQL Essentials, Analytic mode: Reusable object model, and more. The bad taste of the code given by Martin Fowler includes:
-Duplicated code (repeat code): "There are a lot of bad taste, repetition is the worst kind of", this sentence I often speak to their students listen to, but they really understand and practice this sentence is not many people. There are two methods in a class with duplicate code, so you can put the repeating code in another method for invocation by extracting the method, and if there is duplicate code in the two sibling subclasses, the duplicate code can be extracted to the parent class, and if there is duplicate code in the two non-relational classes, Then you can re-extract a class to put repeating code in this third-party class.
-Long method: The longer the program is, the more difficult it is to understand that it is common sense to use a short method to first meet the requirements of high cohesion and to help understand the role of the method by giving it a good name. If you feel that a comment is needed somewhere in the method, you can put it in a separate method and name it using the purpose (not the implementation method).
-Large Class (huge classes): If you want to write a class to do a lot of things, then eventually it will inevitably lead to repetitive and confusing code. The design of a class should follow a single responsibility principle (SRP). Refactoring a huge class can use the extraction interface to figure out how this class should be decomposed.
-Long Parameter list: This is familiar to programmers who have done Windows programming or used MFC (Microsoft Foundation Class). Windows functions and methods in MFC Those perverted argument lists are nightmares for programmers. Refactoring is a lot of ways, it is more common to organize the relevant parameters into an object to replace these parameters.
-Divergent change (decentralized variability) and shotgun surgery (shotgun surgery): Both of these bad flavors are difficult to add to the former, which says that some changes will trigger multiple details. Simply put, if the variables in the program are scattered all over the code, then the maintenance of the code will be a nightmare. The refactoring method is to find all the changes caused by a particular cause and then extract them into another class. The bridge pattern in design mode is the solution provided to solve this problem.
-Feature Envy: This is really not a good idea how to translate is easier to understand, simply is one way to get a lot of value from the object of another class, the refactoring scheme is to move the method to another class. It sounds simple, but often forgets to do so in practice.
-Data clumps: a condition similar to a long parameter list.
-Primitive obsession (basic type Paranoia). If there are many basic types of members in a class, you can often consider dispersing different primitive types into objects, like a combined mapping in Hibernate, embedding objects of one class as members of another class instead of just one class, with many members of the base data type.
-Switch statements (duplicate switch statement): An obvious feature of an object-oriented program is to replace the switch structure with polymorphism, because the switch structure repeats in multiple places.
-Parallel inheritance hierarchies (parallel inheritance structure): The situation is similar to Shortgun surgery, which can be reconstructed using bridge mode.
-Lazy Class (redundant): If a class is not worth being, it should disappear.
-Speculative generality (speculative versatility): If your abstract class, delegate, and method parameters do not actually function, then you should be removed.
-Temporary field (temporary fields): A field in a class is set only for certain special cases.
-Message Chains: I don't personally feel how bad this is.
-Middle man (middleman): If many of the functions of a class are done by delegating to other classes, then it's better to get rid of these middlemen to deal directly with objects that are actually responsible.
-Inappropriate intimacy (too close): Using inheritance multiplexing code can often cause this problem, because subclasses are always more aware of the parent class than the latter, and if you think the child can live on his own, let it leave the inheritance system, This is in keeping with the principle of object-oriented design in the principle of synthetic aggregation multiplexing.
-Alternative Classes with Different Interfaces (similar): Two ways to do the same thing with a different signature.
-Incomplete library class (incomplete class libraries).
-Data class: Degenerate structure of the class. The business entity in the blood loss model (transactional scripting pattern) we often use in layered development is not the data class, which is obviously contrary to the idea of object-oriented.
-Refused bequest (Reject Legacy): If subclasses reuse the behavior of the parent class and do not want to support the interface of the parent class, consider using a synthetic relationship aggregation relationship instead of an inheritance relationship to eliminate this bad taste.
-Comments (note bad code): comments are not used to remedy poor-quality code, in fact, if we go beyond the code of all the good taste, when the poor code is removed, the comment has become redundant, because the code has already made clear everything.

?? The way to completely eradicate these bad smells in code is to provide about 70 refactoring recommendations in the sixth to 12th chapters of refactoring, and some of the common refactoring recommendations are found in the IDE's refactoring menu. The refactoring menu for Eclipse is as shown.

"Refactoring: Improving the design of existing code" reading notes