Reconstructing heart--increasing code reuse rate

because now the Internet business is busy, leading to product dog constantly ask for demand, but also always change to change, and finally left the program ape time less. Program Ape is not vegetarian, simply copy the code casually to do the implementation of the function on the line, there is no so-called elaborate design. This is indeed shortened development time, but everywhere is duplicated code, greatly improved the cost of software maintenance, for the future development of software has brought hidden trouble. If the same function has been copied and pasted hundreds of times, once this code needs to change, it is a disaster, changed this way and forgot to change over there. The same piece of code, when you copy the first time may be tolerated, but the second time, you should stop to think about it, this is a good programming habits, we have to abide by the dry principle.

we should pay more attention to functions or classes that have similar or similar functions, because they are prone to large numbers of identical or similar code, and they should be reused. However, due to the unreasonable structure of the past, too much coupling with other programs, lack of developer awareness, and even due to development time constraints, they are simply copied, so we should refactor them.

• When duplicate code exists in the same object, which means that a piece of code appears more than two times in that object, we should extract the code as a method.
• When duplicate code is not in the same object, use the method of extracting the class to extract the repeating part into a tool class, and then let the other class call.
• When duplicate code is not in the same object, if there is a strong business affinity for these duplicated code, you can extract and marshal the code into an entity class that can reflect this business dependency.
• When duplicate code is not in the same object, you can also extract the same part as the parent class, and the different parts remain in the original class, and then let the other classes inherit the parent class.
• When inheritance flooding occurs, different parts are resolved by using an interface with multiple implementations, which is the combination.
• When refactoring code is divided into fragments by the same part and different parts, that is, the same and not the same inclusions, and this time most of the order, how to break? It is very simple to define a parent class that breaks down into several sequential methods (each method is a step), the same part of the code is written in the parent class, and the different parts implement their own steps in the subclass.

When should I use inheritance and when should I use a combination?

• If there is a is-a relationship (such as Bee "is a" insect), and one class needs to expose all the method interfaces to another class, then the inheritance mechanism should be used.
• If there is a has-a relationship (such as Bee "has a" attack function), then the combination should be used.

Reconstructing heart--increasing code reuse rate