Analysis of 21 types of errors most likely to be committed by writing Java programs

1. Duplicated code

Code repetition is almost the most common odor. He is also one of the main goals of refactoring. Code duplication often comes from the copy-and-paste programming style. Oaoo is an important indicator of a good system.

2. Long Method

It is a traditional structured "Legacy drug ". A method should have self-independent intentions and should not put together several intentions.

3. Large Class

The main category is that you give too many responsibilities to one class. The rule here is one class one responsibility.

4. Divergent change

The content change rate in a class is different. Some statuses change once an hour, while some changes only once a few months a year. Some statuses change because of this, while others change once for other reasons. Object-oriented abstraction is to isolate relatively unchanged and relative changes. Isolate one aspect of the problem change from the other. This makes these relatively unchanged items reusable. Every aspect of the problem change can be reused independently. The coexistence of such different changes makes reuse very difficult.

5. Shotgun surgery

This is exactly the opposite of the above. Changes in one place of the system involve changes in many other places. These States and actions with similar change rates and changes should generally be placed in the same class.

6. Feature envy

The purpose of an object is to encapsulate the state and the behavior closely related to these States. If a class method frequently uses the get method to access the states of other classes for calculation, you should consider moving the behavior to the class with the largest number of States involved.

7. Data clumps

Some data is usually played in groups like children: it appears together in many class member variables and in many method parameters. These data may be independent objects.

8. Primitive obsession

Object-oriented beginners usually use several primitive types of data to represent a concept. For example, for a range, they use two numbers. For money, they are represented by a floating point number. Because you do not use objects to express the concepts that exist in the problem, this makes the code difficult to understand, and the difficulty of solving the problem is greatly increased. The good habit is that the Extended Language can provide the original type, and small objects are used to represent the range, amount, conversion rate, zip code, and so on.

9. Switch statement

Constant-based switch statements are the enemy of OO. You should change them to subclass, state, or strategy.

10. Parallel inheritance hierarchies

The inheritance hierarchy of parallelism is a special case of shotgun surgery. Because when you change a class in a hierarchy, you must change the parallel subclass of another hierarchy at the same time.

11. Lazy class

A class that does not work much. Class maintenance requires additional overhead. If a class bears too few responsibilities, it should be eliminated.

12. Speculative generality

A class implements functions and versatility that have never been used. Generally, the only user of such a class or method is testcase. Do not hesitate to delete it.

13. Temporary Field

Attributes of an object may only make sense in some cases. Such code is hard to understand. Create an object to hold such orphan attributes, and move the behavior associated with the object to this class. The most common is that a specific algorithm requires certain variables that are useful only to this algorithm.

14. message chain

Message chain occurs when a customer requests another object to one object, then the customer requests another object to the other object, and then requests another object to the other object. In this case, you need to hide the assignment.

15. middle man

One of the basic features of an object is encapsulation, which is often encapsulated by dispatching. However, this step cannot go too far. If you find that most of the Methods of A Class interface are being distributed, you may need to move to this intermediary.

16. Inappropriate intimacy

Some classes are too close to each other, and they spend too much time building the private part of others. For humans, we may not be too serious, but we should keep our classes strictly under assilence.

17. Alternative classes with different interfaces

The methods for doing the same thing have different functions signature. They are moved to the class level until the protocols are consistent.

18. Incomplete Library Class

It is very difficult to establish a good class library. A lot of our program work is implemented based on class libraries. However, such broad and distinct goals impose demanding requirements on Database builders. Library builders are not omnipotent. Sometimes we will find that the library class cannot implement the functions we need. However, it is very difficult to directly modify the library class. At this time, various methods are required for refactoring.

19. Data class

Objects include statuses and behaviors. If a class has only the status and no behavior, there must be something wrong.

20. Refused bequest

The superclass transmits many behaviors and States, and the subclass only uses a small part of them. This usually means that there is a problem with your class hierarchy.

21. Comments

I often think that writing a lot of comments is hard to understand your code. If it feels too much, you need refactoring.