commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [OGNL] God Class
Date Wed, 18 May 2011 00:41:17 GMT
On 18 May 2011 00:17, Stephen Williams <sdw@lig.net> wrote:
> 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.

+1, totally agree.

Now if the 5000 lines of code was in a single method with very deeply
nested conditionals and loops spanning hundreds of LOC, that would be
a different matter.

But a class that contains a lot of short methods? No problem if they
are properly organised.
Or even a very long method is OK, so long as it can be followed
sequentially with no big back-tracking needed.

Even a very short class can be very confusing if the layout is poor
and the variables are badly named, or the conditionals are reversed
from normal expectations.

> 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 sdw@lig.net stephendwilliams@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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message