Home » Eclipse Projects » Standard Widget Toolkit (SWT) » ideal size of classes in Eclipse/Java
| ideal size of classes in Eclipse/Java [message #445185] |
Wed, 27 October 2004 15:29  |
Eclipse User |
|
|
|
Originally posted by: dominique.vlieghe.dmbr.ugent.be
Hello all,
I have a more phylosophical question. Some time ago I started my
first-ever Java project, and of course I use eclipse (on Linux). In the
beginning everything went well, but gradually with the amount of lines,
Eclipse is starting to get slow and often lags.
I have one major class of about 10000 lines, wherein the bulk of my UI
methods are contained. Besides that, I have about 15 other classes with
mostly non-UI objects.
Question now is: what is the optimal size of a class? Is a class of
10000 lines normal in normal java projects? Does one generally put the
UI related methods in one big class or not? Are there ways to speed up
Eclipse (without losing too much of its functionality such as automatic
syntax checking) or should I consider splitting up my UI class?
Hope to hear from the experts,
Regards,
Dominique
|
|
| |
| Re: ideal size of classes in Eclipse/Java [message #445197 is a reply to message #445193] |
Thu, 28 October 2004 06:52  |
| Eclipse User |
|
|
|
Originally posted by: dominique.vlieghe.dmbr.ugent.be
Christophe Cornu wrote:
>>I have one major class of about 10000 lines
>
> We want to see it :-)
>
>
>
So, from your answer I gather that this is not quite common :-) I must
say that the number doesn't say it all. The class contains a lot of code
that can be rewritten more compact, but at the time I was still learning
java...
Seriously now, I'd really like your opinions...
Regards
Dominique
|
|
| |
| Re: ideal size of classes in Eclipse/Java [message #445199 is a reply to message #445198] |
Thu, 28 October 2004 07:37 |
| Eclipse User |
|
|
|
Originally posted by: js.ekkono.com
Dominique,
10K lines in one class is absolutely tooooo much. Most likely your class
is handling events, updating business objects, rendering some stuff, and
so forth.
Please don't get me wrong: IMHO you are not really programming OO. The
good news is: you realized that there is place for improvement - most
people don't ever.
One of the most difficult problems of OOP is finding the right
abstraction. And in contrast to most OOP books, I don't think thinking
about table, chair, and other real world objects is a good way to start
doing that. We did just that, and ended up with classes with similar size
(max 7K).
How I would suggest you handle the problem (it worked for us our code base
went from 150K to 50K total while we added functionality).
1) Read Martin Fowler's book "Refactoring": It shows basic low level ways
to use objects to simplify your design. Look how the Strategy pattern is
used to distribute responsibility over different classes. A broader
picture is in Martin's Agile Software Development (I'm not a great fan of
XP, but the ideas about OOP are excellent).
2) Try to find information on the MVC pattern. I guess you are breaking
it in various ways.
3) Never ever allow parts of your code to rot!!! If you tell me you could
do it better, that means you should do it better!
I hope this gives a place where you can start.
Cheers,
Joerg
|
|
|
| Re: ideal size of classes in Eclipse/Java [message #445200 is a reply to message #445198] |
Thu, 28 October 2004 07:38 |
| Eclipse User |
|
|
|
Originally posted by: dominique.vlieghe.dmbr.ugent.be
Benjamin Pasero wrote:
> I was in a similiar situation with a single class containing the entire
> GUI. I then got problems handling the code, since it was hard to see
> through. And even worse Eclipse (ok it was 2.1 ;) ) took so much resources
> on that class that working with it was no longer possible. I extracted
> most parts into new classes, where it made sense. For example creating
> classes of certain areas of the GUI.
> So, what is that class containing?
>
Sounds very familiar :-) Do you have a rough estimate of class sizes
(before the split)?
My major class contains all widgets. I have one parent shell, onto which
I have one menubar on top and 3 major widgets (a tree, a textwindow and
a scrollable/zoomable canvas. All my own (non-UI) classes are in
seperate files. I have non-graphical elements, and graphical elements
that represent the non-graphical ones. So I have a lot of necessary
back and forth communication.
I could consider to split up my UI elements, but
a) its a lot of work I guess
b) I would have to redefine some global variables/lists. Those global
variables might not be 'good programming practice', but they are damn handy.
c) Problem is also that my menubar, my tree and canvas share related
functionality (i.e. widgets), so I don't really see how to handle this
correctly/elegantly.
>
>>Christophe Cornu wrote:
>>
>>>>I have one major class of about 10000 lines
>>>
>>>We want to see it :-)
>>>
>>>
>>>
>>
>>So, from your answer I gather that this is not quite common :-) I must
>>say that the number doesn't say it all. The class contains a lot of code
>>that can be rewritten more compact, but at the time I was still learning
>>java...
>
>
>>Seriously now, I'd really like your opinions...
>
>
>>Regards
>
>
>>Dominique
>
>
>
|
|
|
| Re: ideal size of classes in Eclipse/Java [message #445202 is a reply to message #445200] |
Thu, 28 October 2004 10:00 |
 Benjamin Pasero
Messages: 337
Registered: July 2009 |
Senior Member |
|
|
Ok, splitting up one big class containing all GUI elements into seperate
ones is a very difficult task. I had the same problems. But with the help
of Eclipse and its refactoring tools it was no problem. From my main GUI
class I came to:
(attention: This is not real/best MVC, but it works)
o Controller
- Loader Class with the Main Method (12kb)
- Main Controller Class putting all things together (34kb)
- TabFolder Class, Menu Class, Tree Class, Table Class and so on, each
of them not bigger than about 1000 lines of code. The Main Controller
is instantiating those and creates the GUI out of it. The good thing
with the main controller is, that that class is knowing about all GUI
elements. The Main Controller is my single big GUI class from the
beginning with the removed GUI elements (like Table, Tree)
o Model
- Reflects the state of the "database". In my case containing information
about newsfeeds that are passed to the controller and displayed in the
GUI elements
- also containing some business logic. Unfortunately not enough I guess.
o DAO
- Getting data from the database or an URLConnection. Filling the model
objects with data.
o Util
- This package turns out to be the biggest one. Lots of helper methods
and
stuff that does not belong to model, view or controller was placed
here.
Hope that helps.
Ben
> Benjamin Pasero wrote:
> > I was in a similiar situation with a single class containing the entire
> > GUI. I then got problems handling the code, since it was hard to see
> > through. And even worse Eclipse (ok it was 2.1 ;) ) took so much resources
> > on that class that working with it was no longer possible. I extracted
> > most parts into new classes, where it made sense. For example creating
> > classes of certain areas of the GUI.
> > So, what is that class containing?
> >
> Sounds very familiar :-) Do you have a rough estimate of class sizes
> (before the split)?
> My major class contains all widgets. I have one parent shell, onto which
> I have one menubar on top and 3 major widgets (a tree, a textwindow and
> a scrollable/zoomable canvas. All my own (non-UI) classes are in
> seperate files. I have non-graphical elements, and graphical elements
> that represent the non-graphical ones. So I have a lot of necessary
> back and forth communication.
> I could consider to split up my UI elements, but
> a) its a lot of work I guess
> b) I would have to redefine some global variables/lists. Those global
> variables might not be 'good programming practice', but they are damn handy.
> c) Problem is also that my menubar, my tree and canvas share related
> functionality (i.e. widgets), so I don't really see how to handle this
> correctly/elegantly.
> >
> >>Christophe Cornu wrote:
> >>
> >>>>I have one major class of about 10000 lines
> >>>
> >>>We want to see it :-)
> >>>
> >>>
> >>>
> >>
> >>So, from your answer I gather that this is not quite common :-) I must
> >>say that the number doesn't say it all. The class contains a lot of code
> >>that can be rewritten more compact, but at the time I was still learning
> >>java...
> >
> >
> >>Seriously now, I'd really like your opinions...
> >
> >
> >>Regards
> >
> >
> >>Dominique
> >
> >
> >
|
|
|
| Re: ideal size of classes in Eclipse/Java [message #445203 is a reply to message #445202] |
Thu, 28 October 2004 10:02 |
Benjamin Pasero
Messages: 337
Registered: July 2009 |
Senior Member |
|
|
I should add that it probably makes more sense to move the GUI elements
into a package "view" out of the "controller" package. As I mentioned, my
approach is not real MVC.
> Ok, splitting up one big class containing all GUI elements into seperate
> ones is a very difficult task. I had the same problems. But with the help
> of Eclipse and its refactoring tools it was no problem. From my main GUI
> class I came to:
> (attention: This is not real/best MVC, but it works)
> o Controller
> - Loader Class with the Main Method (12kb)
> - Main Controller Class putting all things together (34kb)
> - TabFolder Class, Menu Class, Tree Class, Table Class and so on, each
> of them not bigger than about 1000 lines of code. The Main Controller
> is instantiating those and creates the GUI out of it. The good thing
> with the main controller is, that that class is knowing about all GUI
> elements. The Main Controller is my single big GUI class from the
> beginning with the removed GUI elements (like Table, Tree)
> o Model
> - Reflects the state of the "database". In my case containing information
> about newsfeeds that are passed to the controller and displayed in the
> GUI elements
> - also containing some business logic. Unfortunately not enough I guess.
> o DAO
> - Getting data from the database or an URLConnection. Filling the model
> objects with data.
> o Util
> - This package turns out to be the biggest one. Lots of helper methods
> and
> stuff that does not belong to model, view or controller was placed
> here.
> Hope that helps.
> Ben
> > Benjamin Pasero wrote:
> > > I was in a similiar situation with a single class containing the entire
> > > GUI. I then got problems handling the code, since it was hard to see
> > > through. And even worse Eclipse (ok it was 2.1 ;) ) took so much
resources
> > > on that class that working with it was no longer possible. I extracted
> > > most parts into new classes, where it made sense. For example creating
> > > classes of certain areas of the GUI.
> > > So, what is that class containing?
> > >
> > Sounds very familiar :-) Do you have a rough estimate of class sizes
> > (before the split)?
> > My major class contains all widgets. I have one parent shell, onto which
> > I have one menubar on top and 3 major widgets (a tree, a textwindow and
> > a scrollable/zoomable canvas. All my own (non-UI) classes are in
> > seperate files. I have non-graphical elements, and graphical elements
> > that represent the non-graphical ones. So I have a lot of necessary
> > back and forth communication.
> > I could consider to split up my UI elements, but
> > a) its a lot of work I guess
> > b) I would have to redefine some global variables/lists. Those global
> > variables might not be 'good programming practice', but they are damn
handy.
> > c) Problem is also that my menubar, my tree and canvas share related
> > functionality (i.e. widgets), so I don't really see how to handle this
> > correctly/elegantly.
> > >
> > >>Christophe Cornu wrote:
> > >>
> > >>>>I have one major class of about 10000 lines
> > >>>
> > >>>We want to see it :-)
> > >>>
> > >>>
> > >>>
> > >>
> > >>So, from your answer I gather that this is not quite common :-) I must
> > >>say that the number doesn't say it all. The class contains a lot of code
> > >>that can be rewritten more compact, but at the time I was still learning
> > >>java...
> > >
> > >
> > >>Seriously now, I'd really like your opinions...
> > >
> > >
> > >>Regards
> > >
> > >
> > >>Dominique
> > >
> > >
> > >
|
|
|
| Re: ideal size of classes in Eclipse/Java [message #445210 is a reply to message #445203] |
Thu, 28 October 2004 13:19 |
| Eclipse User |
|
|
|
Originally posted by: dominique.vlieghe.dmbr.ugent.be
Benjamin and Joerg, thank you very much for the informative replies: now
I can start reading all about MVC, Refactoring (things I never heard
of untill some hours ago) and hopefully I will get it straight.
Meanwhile, I'm trying your suggestions on a small subtask in my project,
being the management of my standard colors and colorScales.
For the other newbies around, MVC is an elegant way of decoupling your
work horse classes from the GUI classes/methods/widgets/..., which
facilitates your project management. There is a nice tutorial on MVC at
http://csis.pace.edu/~bergin/mvc/mvcgui.html
check it out!
Benjamin Pasero wrote:
> I should add that it probably makes more sense to move the GUI elements
> into a package "view" out of the "controller" package. As I mentioned, my
> approach is not real MVC.
>
>
>>Ok, splitting up one big class containing all GUI elements into seperate
>>ones is a very difficult task. I had the same problems. But with the help
>>of Eclipse and its refactoring tools it was no problem. From my main GUI
>>class I came to:
>
>
>>(attention: This is not real/best MVC, but it works)
>
>
>>o Controller
>> - Loader Class with the Main Method (12kb)
>> - Main Controller Class putting all things together (34kb)
>> - TabFolder Class, Menu Class, Tree Class, Table Class and so on, each
>> of them not bigger than about 1000 lines of code. The Main Controller
>> is instantiating those and creates the GUI out of it. The good thing
>> with the main controller is, that that class is knowing about all GUI
>> elements. The Main Controller is my single big GUI class from the
>> beginning with the removed GUI elements (like Table, Tree)
>
>
>>o Model
>> - Reflects the state of the "database". In my case containing information
>> about newsfeeds that are passed to the controller and displayed in the
>> GUI elements
>> - also containing some business logic. Unfortunately not enough I guess.
>
>
>>o DAO
>> - Getting data from the database or an URLConnection. Filling the model
>> objects with data.
>
>
>>o Util
>> - This package turns out to be the biggest one. Lots of helper methods
>>and
>> stuff that does not belong to model, view or controller was placed
>>here.
>
>
>>Hope that helps.
>>Ben
>
>
>>>Benjamin Pasero wrote:
>>>
>>>>I was in a similiar situation with a single class containing the entire
>>>>GUI. I then got problems handling the code, since it was hard to see
>>>>through. And even worse Eclipse (ok it was 2.1 ;) ) took so much
>
> resources
>
>>>>on that class that working with it was no longer possible. I extracted
>>>>most parts into new classes, where it made sense. For example creating
>>>>classes of certain areas of the GUI.
>>>>So, what is that class containing?
>>>>
>
>
>>>Sounds very familiar :-) Do you have a rough estimate of class sizes
>>>(before the split)?
>
>
>
>>>My major class contains all widgets. I have one parent shell, onto which
>>>I have one menubar on top and 3 major widgets (a tree, a textwindow and
>>>a scrollable/zoomable canvas. All my own (non-UI) classes are in
>>>seperate files. I have non-graphical elements, and graphical elements
>>>that represent the non-graphical ones. So I have a lot of necessary
>>>back and forth communication.
>
>
>>>I could consider to split up my UI elements, but
>>>a) its a lot of work I guess
>>>b) I would have to redefine some global variables/lists. Those global
>>>variables might not be 'good programming practice', but they are damn
>
> handy.
>
>>>c) Problem is also that my menubar, my tree and canvas share related
>>>functionality (i.e. widgets), so I don't really see how to handle this
>>>correctly/elegantly.
>
>
>>>>>Christophe Cornu wrote:
>>>>>
>>>>>
>>>>>>>I have one major class of about 10000 lines
>>>>>>
>>>>>>We want to see it :-)
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>So, from your answer I gather that this is not quite common :-) I must
>>>>>say that the number doesn't say it all. The class contains a lot of code
>>>>>that can be rewritten more compact, but at the time I was still learning
>>>>>java...
>>>>
>>>>
>>>>>Seriously now, I'd really like your opinions...
>>>>
>>>>
>>>>>Regards
>>>>
>>>>
>>>>>Dominique
>>>>
>>>>
>>>>
>
>
|
|
|
| Re: ideal size of classes in Eclipse/Java [message #445214 is a reply to message #445185] |
Thu, 28 October 2004 13:56 |
Paul Singleton
Messages: 37
Registered: July 2009 |
Member |
|
|
Dominique Vlieghe wrote:
> Question now is: what is the optimal size of a class? Is a class of
> 10000 lines normal in normal java projects? Does one generally put the
> UI related methods in one big class or not? Are there ways to speed up
> Eclipse (without losing too much of its functionality such as automatic
> syntax checking) or should I consider splitting up my UI class?
I maintain a 19,500 line class (it's the "session bean"
behind a JSP web app) and find that Eclipse 3.0 handles this
OK where 2.1 didn't (long, unpredictable periods of 100% cpu
and editor nonresponsiveness) (under XP Pro).
I think it's important to have enough physical RAM, as I
strongly suspect that Sun's JVMs cause more paging than an
oversized native app typically would (maybe it's an MS dirty
trick?!)
I briefly tried the IBM 1.4.2 SDK in case it was faster, but
had problems with Tomcat and Jikes, and had to revert (to get
some real work done). But if there's evidence that it's usefully
faster (or otherwise better) I'll persevere.
It's not clear to me that development productivity would be
improved by splitting this class up; I can navigate it almost
as easily as if it were 10% of this size. Since HTTP is
stateless, and Tomcat ties requests to sessions, this class
is not complex, just big, handling ever more actions on the
same old session state. I really think this is a special case:
other monolithic programs have got scary long before they got
this big.
What would really make a difference would be better abstraction
mechanisms in Java: there's a lot of similar code which can't
elegantly be factored out. Higher-order functions and code-as-
-data Prolog-style would be good, but even C-style macros would
help :-)
Sorry if this is off-topic, but e.p.swt is the only Eclipse group
I read (am using SWT in a declarative-GUIs-for-Prolog project).
Paul Singleton
|
|
| |
Goto Forum:
Current Time: Wed Apr 24 17:26:49 GMT 2024
Powered by FUDForum. Page generated in 0.03932 seconds |
] 
Search
Help
Register
Login
Home
