commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
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!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Wed, May 18, 2011 at 2:41 AM, sebb <sebbaz@gmail.com> wrote:
> 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
>
>

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


Mime
View raw message