| Primitive Obsession | Use small objects to represent data such as money (which combines quantity and currency) or a date range object | |
| Data Class | Classes with fields and getters and setters and nothing else (aka, Data Transfer Objects – DTO) | |
| Data Clumps | Clumps of data items that are always found together. | |
| Refused Bequest | Subclasses don’t want or need everything they inherit.
The Liskov Substitution Principle (LSP) says that you should be able to treat any subclass of a class as an example of that class. |
|
| Inappropriate Intimacy | Two classes are overly entertwined. | |
| Lazy Class | Classes that aren’t doing enough should be refactored away. | |
| Feature Envy | Often a method that seems more interested in a class other than the one it’s actually in. In general, try to put a method in the class that contains most of the data the method needs. | |
| Message Chains | This is the case in which a client has to use one object to get another, and then use that one to get to another, etc. Any change to the intermediate relationships causes the client to have to change. | |
| Middle Man | When a class is delegating almost everything to another class, it may be time to refactor out the middle man. | |
| Divergent Change | Occurs when one class is commonly changed in different ways for different reasons. Any change to handle a variation should change a single class. | |
| Shotgun Surgery | The opposite of Divergent Change. A change results in the need to make a lot of little changes in several classes. | |
| Parallel Inheritance Hierarchies | A special case of Shotgun Surgery. Every time you make a subclass of one class, you also have to make a subclass of another. |