Speculative Generality

Speculative Generality

Symptoms

• There are unused classes, methods , fields, parameters, and such. They may have no clients or only tests as clients .

• Code is more complicated than it has to be for the currently implemented requirements.

Causes

The code may be built with the expectation that it will become more useful, but then it never does. When people try to outguess the needs of the code, they often add things for generality or for completeness that end up never being used. Sometimes the code has been used before, but is no longer needed because of new or revised ways of doing things. ( Speculative Generality may be Dead Code created on purpose.)

What to Do

• For an unnecessary class:

  • If parents or children of the class seem like the right place for its behavior, fold it into one of them via Collapse Hierarchy.

  • Otherwise, fold its behavior into its caller via Inline Class.

• For an unnecessary method, use Inline Method or Remove Method.

• For an unnecessary field, ensure there are no references and then remove it.

• For an unnecessary parameter, use Remove Parameter .

Payoff

Reduces size. Improves communication. Improves simplicity.

Contraindications

• If your application is a framework, you may have elements present to support clients' needs that, strictly speaking, aren't needed by the framework itself. For example, a class may have an empty hook method that will be called by (not-yet-existing) subclasses.

• Some elements are used by test methods, but they're exposed as test probe points to allow a test to have privileged information about the class. Be careful though ”this may indicate that you're missing an abstraction that you could test independently.

Exercise 12 Today versus Tomorrow.

To caricaturize the arguments:

XP argues that speculative generality is a smell, and that you aren't going to need it. That is, make your code meet today's requirements, and don't try to anticipate which way tomorrow's requirements will go. (Thus an XP team is more likely to evolve a framework from an application than to build a framework and use it to create an application.)

Another approach is to design for flexibility or to design for generality. This means that you should fully flesh out your classes based on the expected requirements.

What are the forces that will help you decide which approach is better?

Forces that make it better to design for only today's requirements today

Forces that make it better to design for tomorrow's requirements today

See Appendix A for solutions.