LikeLike

It is fine in principle. However, in practice there are two problems. First, one do not have a narrow problem to begin with. The natural process is to have a general problem, and as we work, we factor into smaller and smaller problems. So this principle is rather the end results of re-factoring. Without this context, people often try to factor their problems over jealously and over maturely, resulting in wrong factors and obscuring the bigger problems. Refactoring is good process from top down, not bottom up. To re-organize the existing factors often is a difficult and costly process, especially after these factors being fully integrated into a web.

Second, it is not always better to have the code factored. Each factor does not come free, it comes with its wraps and connectors, scopes and interfaces. So the refactoring process is really a constant balance of cost/benefits, the criterion being the manageability on the comprehension and maintenance. I emphasize balance here, treating this rule as a golden rule is responsible for some of the nightmares.

LikeLike