commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <>
Subject Re: [OGNL] God Class
Date Wed, 18 May 2011 06:56:13 GMT
Hi Murizio,
it is indeed hard sometimes manage some classes, but take also in
consideration that some of them - like the OgnlParser - are generated
by JavaCC and should not versioned in the SCM at all, there's an open
issue about it (OGNL-)
My suggestion would be: let's make first the current OGNL
implementation compliant to Apache Commons policy - that's the one has
been serving the OGNL usres for years - once released we can start
brainstorming about improvements. WDYT?
Thanks in advance, have a nice day!

On Wed, May 18, 2011 at 2:41 AM, sebb <> wrote:
> On 18 May 2011 00:17, Stephen Williams <> 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/
>>> 1139 ./src/main/java/org/apache/commons/ognl/
>>> 1858 ./src/main/java/org/apache/commons/ognl/
>>> 3038 ./src/main/java/org/apache/commons/ognl/
>>> 4845 ./src/main/java/org/apache/commons/ognl/
>>> ----------------------------------------------------------------------------------------------------------------------
>>> 5000 lines of code... we should consider to rename to
>>> 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]
>> --
>> Stephen D. Williams LinkedIn:
>> V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362
>> F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume:
>> Personal:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message