6000 lines in one class ?

It's almost certainly too many, but it's not a hard-and-fast rule. That length of class suggests the God class anti-pattern. The class probably doesn't have a single clear, defined responsibility. The side-effect is, it's a maintenance nightmare, for one. Another is, it's probably not modelling the problem domain very well. Wouldn't surprise me if it didn't define a real actual object, either, but was more procedural in nature

While we're near the subject, methods should be short, too (in fact, shorter classes usually result naturally by following this) I've heard people say "10 lines is enough" but that's a bit impractical. A screenful is generally large enough

Message was edited by:

georgemc

georgemca at 2007-7-12 23:53:23 >

> In general, I'd say 6000 lines is suspect (aka a

> "code smell"). It is very likely that your class has

> too many responsibilities.

>

> Separating concerns should be a design goal. For

> example, don't make one class responsible for

> communicating with the database, the business logic

> and the UI, use separate classes.

>

> There are no side-effects pers? other than having to

> deal with what is in all likelihood a tangled mess of

> unmaintainable code.

A potential side-effect is that there are disparate classes dependent on it, and the refactoring of this god class for the benefit of one such dependent, could adversely affect the behaviour of another

georgemca at 2007-7-12 23:53:23 >

well, what is "normal"?

All depends of course. My current project has a main class that's 328 lines. That's the largest single class in the project (except maybe some 3rd party libraries it depends on (indirectly)).

The smallest class is an enum that's just 10 lines (including the package name, whitespace, and 4 lines of documentation).

Neither class is wider than 120 characters (so it fits on screen without horizontal scrolling and prints without breaking lines).

Another project has several very large classes, mainly because they do some rather complex stuff that can't be easily written in a more terse way (though things could be refactored I guess, they've grown over time as more and more fields needed to be parsed from the input they get, each field requiring a number of lines of code).

jwentinga at 2007-7-12 23:53:23 >