The sub-method handles too many situations

Refactoring code often encounters a sub-method (or Class) with complex if-else that can handle a variety of situations.

At this point the caller of the method seems simple enough to simply call the method. But in fact, all the complex logic falls to the sub-method clock.

As a result, the original non-correlated callers of the child methods also become mutually coupled. That is, I just want to modify the child method because caller a, because the child method is modified, other callers may be affected by the hash. Modification of a child method must take into account the actual usage of its various callers.

So the more the sub-method, the more it should deal with less cases. The complex logic is given to the caller for processing. Of course, if it is simply multiple state processing, such as determining whether the string address is empty in strcpy, it is easier to handle both empty and non-empty cases without affecting the difficulty of comprehension or in sub-methods.

The sub-method handles too many situations