What can be said about this java class?

I was asked this question : I was not able to answer - Any answers 开发者_如何学运维here?

What can be said about a java class which has 1000 lines of code , with 1-n methods having 100 lines and n+1 to m methods having 200 lines of code?

I thought, Classes should be okay to have 1000 lines of code and methods are also okay to have 100-200 lines of code - So I didn't answer considering that the class is perfectly okay.

Are there known compile time performance related to the number of lines a java class has? or a java method has ? are there any standards - if so, how can one justify technically?

thanks!

What can be said about this class it that it must be refactored. It has too many lines of code per class, and per method. It doesn't cause any technical problems, but it causes readability and support problems.

I think that the main problem here is not the compile-time performance. A 1000 lines class is difficult to read and understand.

Perhaps the class should be decomposed in other classes (or subclasses, if in your case inheritance is more valuable than composition), so every class has a well defined responsibility in the system.

But I can't say very much about this problem if I can't view the class' implementation.

There are a lot of good books that explain how to solve this and others design problems. Two well known books are Code Complete 2nd Edition by Steve McConnell and Refactoring by Martin Fowler et al.

What comes to my mind:

n = 0, m-n = 5 --> 5 methods
n = 2, m-n = 4 --> 6 methods
n = 4, m-n = 3 --> 7 methods
n = 6, m-n = 2 --> 8 methods
n = 8, m-n = 1 --> 9 methods
n = 10, m-n = 0 --> 10 methods

Everything else is already mentioned in the other responses.

This sounds like it might be a god object - a very large class that violates the single responsibility principle. Here's another good description of it, including ideas on how to refactor it: The Blob.

Also have a look at anti-patterns.

It's not the compilation time you should be aware of, but maintenance problem. I have myself faced even worse problem recently - I took over code where main class was about 6000 lines long, with very long methods, nested loops and if-statements etc. Trust me, it takes quite an effort for new developer to understand what's going on there.

Ideally each class/method should have only one responsibility and only do one single task. So if I were you I would definitely answer that this class really needs to be refactored!

What can be said? Well, it can be said that the number of method in that class is: m <= 5 + n/2

God class with brain methods - definitely an antipattern. http://www.springer.com/computer/swe/book/978-3-540-24429-5

It means that though you have used OOP language, you have still coded like you often do it in any of the trivial non-structured programming language.

What can be said is that the class is a candidate for refactoring. But, of course, there's no hard and fast rule about how big a class should be, or its methods.

1. The Class's Methods are Candidates for Refactoring

This does not mean the methods should automatically be refactored. There are legitimate cases where a well-designed method might be 100 or even 200 lines long. Consider a method implementing a higher math function which uses large arrays as lookup tables to speed processing for common cases. These arrays are completely internal to the method body, may span many lines of code, yet might not actually add all that much to the methods' complexity.

However these cases are rare, and most of the time you can say methods spanning 100+ lines need to be broken up to be consistent with good design for the variety of reasons already mentioned here (readability, testability, reuse, etc.). Understanding and noting the "corner cases" of when this length may actually be reasonable, and not jumping right into the dogmatic absolutes of "anytime something is X lines long you must do Y" will almost certainly reflect better on you.

2. The Class Itself is a Candidate for Refactoring

As noted by others, there are no absolutes when it comes to how large a class should be in terms of lines of code. However, the Single Responsibility Principle says that a class should do one thing well and one thing only. It is a reasonable assumption that this class is doing more than one thing, based solely on its length, and that the design would benefit from breaking it down in several smaller classes. However, this is by no means a guarantee. A thousand lines isn't absurdly long, and may be merited in some cases. The length of the methods is almost always a larger concern than the length (in lines of code) of the class.

3. Inferences About the Class's Contents

While I suspect there might be a typo in the OP's description of the problem: 1-n methods having 100 lines and n+1 (consider if n is a positive integer greater than 1---you end up with a negative number of 100 line methods). You can begin to reason about the class if you can do a quick calculation about the number of each type of method.

For instance, if 2*a + b = 5 (where a is the # of 100 line methods and b is the # of 200 line methods), then you know that the entire class is comprised of nothing but these methods, because the total # of lines in them would = 1000. In that case, you know the class has no constructors, fields or initializes. Knowing this, it follows that every method must be static. Then you have a class which only exists to provide some longer static methods: sounds like a utility/helper class to me.

You also know the converse: if 2*a + b != 5, the class must possess at least one field, constructor or initializer block.