How do you keep yourself and your co-workers from creating huge classes

Question

Stackoverflow users, How do you keep yourself from creating large classes with large bodied methods. When deadlines are tight, you end up trying to hack things together and it ends up being a mess which would need to be refactored.

For me, the one way was to start with test driven development and that lends itself to good class design as well as the SRP (Single Responsibility Principle).

I also see developers just double clicking on controls and typing out line after line in the event method that gets fired.

What are your suggestions?

Answer 1

I guess it depends on your internal processes as much as anything.

In my company, we practise peer review, and all code that gets comitted must be 'buddied in' by another developer, who you have to explain your code to.

Time constraints are one thing, but if I review code that has heinously long classes, then I won't agree to the check-in.

It's hard to get used to at first, but at the end of the day, it's better for everyone.

Also, having a senior developer who is a champion for good class design, and is willing and able to give examples, helps tremendously.

Finally, we often do a coding 'show and tell' session where we get to show off our work to our peers, it behooves us not to do this with ugly code!

Answer 2

Use a tool like Resharper and the Extract Method command.

Answer 3

Long classes is one bad code smell of many possible.

Remedying overly large classes by creating lots of small ones may create its own problems. New engineers on your project may find it difficult to follow the flow of the code to work out what happens where. One artifact of this problem can be very tall call stacks, execution nesting through many small classes.

Answer 4

We're a java and maven shop, and one of the...I guess you could say forensic methods we use are the excellent FindBugs, PMD and javancss plugins. All will give warnings about excessive length in a method, and the cyclomatic complexity calculations can be very eye opening.

Answer 5

The single most important step for me to avoid large classes that often violate SRP was to use a simple dependency injection framework. This freed me from thinking too much about how to wire things together. I only use constructor injection to keep the design free from cycles. Tools like Resharper help to initialize fields from constructor arguments. This combination leads to a near zero overhead for creating and wiring up new classes, and implicitly encourages me to structure behavior in much more detail.

This all works best if data is kept separate from behavior, and your language supports constructs like events that can be used to decouple communication that flows in the downward direction of the dependency graph.

Answer 6

use some static code analysis tools in your automated builds and write/configure/use some rules so that for example someone has to write a justification when he/she breaks it..

Answer 7

Another suggestion is to do only what is asked. Don't play the "What if" game and try to overdesign a solution. This has the "Keep it simple, stupid" idea behind it.