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 <seb...@gmail.com> wrote: > On 18 May 2011 00:17, Stephen Williams <s...@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 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 >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
