The opposite, ravioli classes or when it goes very badly: "class diarrhea" (my term, see below), can be worse. When breaking down a
business application, giant objects are usually a problem and something to avoid. When A) solving a complex and tightly integrated
problem that should be used as single object by other code and/or B) when hanging many type-specific algorithms, convenience
methods, adapters, etc., it can be entirely appropriate. Good examples might be the many methods hanging off of Java String, or key
classes in GUI frameworks (Activities and Views in Android for instance).
Size is not as important as lowest total complexity of the interface and of usage. Lines of code can be informative, but shouldn't
be the prime reason to change design. The main reason I've seen people have a problem is when they are using editors and IDEs that
don't handle large files very well. With Emacs and Eclipse, I have no problems at all. I use both at once to get the best of both.
When building a library, lowest complexity and difficulty of usage rules, IMHO.
I've seen the opposite: Had an offshore team create 600+ classes in <6 months, glued together in all kinds of ways (including regexp
matching of resources loaded from XML files). Actual lines of code was <10 per class. Just about all of them were involved for an
operation of the system. I probably would have done it with <50 classes. Development eventually ground to a halt because even the
original authors couldn't successfully make changes after a while.
Stephen
On 5/17/11 4:01 PM, Maurizio Cucchiara wrote:
if there is something I hate in programming is the god class [1].
OGNL seems to embrace god object's cause pretty well.
----------------------------------------------------------------------------------------------------------------------
find -size +30k -name "*.java"| xargs -i sh -c "wc -l {}" | sort -n
771 ./src/main/java/org/apache/commons/ognl/Ognl.java
1139 ./src/main/java/org/apache/commons/ognl/OgnlOps.java
1858 ./src/main/java/org/apache/commons/ognl/OgnlParserTokenManager.java
3038 ./src/main/java/org/apache/commons/ognl/OgnlRuntime.java
4845 ./src/main/java/org/apache/commons/ognl/OgnlParser.java
----------------------------------------------------------------------------------------------------------------------
5000 lines of code... we should consider to rename to Bible.java
Jokes apart, it's very difficult to handle a class like this, if you
change something it's highly probable to broke the whole logic. I
think that everybody is afraid of manage a such big class.
We could maintain the API backward compatibility even trying to
improve this aspect.
What do you think?
[1] http://en.wikipedia.org/wiki/God_object
--
Stephen D. Williams s...@lig.net stephendwilli...@gmail.com LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX
V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st
facebook.com/sdwlig twitter.com/scienteer
