Large source code files



  • I've never worked on a large application before so a buddy of mine and I decided to make ourselves a big GUI program.  We're using java and the enviroment we are using is Eclipse Visual Editor.  Anyways our program has about 15 screens and lots (and lots) of dialog boxes.  we're not even half done with the GUI and the main view class is already approaching 10,000 lines.  normally I wouldn't care how large it is but the reverse parser for VE is starting to get pretty laggy while we type code.  I've been thinking about putting all the dialog boxes in a seperate class but it seems like kind of a stupid hack.  Does anyone have advice or know what would be considered best practice here?



  • @tster said:

    ...the main view class is already approaching 10,000 lines.


    <font size="6">WTF?!</font>

    Generally a class should have a single, clearly-defined responsibility.  It sounds like this "main view class"'s responsibility is very, very vague: "display the UI".  Break it up into smaller, more specialized classes.



  • @tster said:

    I've been thinking about putting all the dialog boxes in a seperate class but it seems like kind of a stupid hack.

    That's probably a good place to start. Out of interest, why would you that's not a good idea?



  • Seems like a "god object" antipattern to me. Advice: Use the refactoring tools of Eclipse to break the monster into smaller classes with well-defined responsibilities.



  • @ammoQ said:

    Seems like a "god object" antipattern to me. Advice: Use the refactoring tools of Eclipse to break the monster into smaller classes with well-defined responsibilities.

    Second advice: read Martin Fowler's "Refactoring", it may be $60 (if you ever manage to find a new copy) but by god you won't consider them wasted.



  • tster is using a visual GUI enditor - those tend to stop working if you change the structure of the code manually.



    Not I don't know eclipse Visual Editor, but it should be possible to
    split up the GUI into separate sections, each consisting of one panel
    or tab and holding no more than 20 or 30 GUI widgets. Each of them
    becomes a separate GUI class that you can edit in the enditor. Your
    main GUI class then uses these classes like you use the basic widgets;
    the editor should have some way to import them as Java Beans.



    The dialogs should definitely be separate classes as well, and you
    shouldn't put the application logic into the GUI classes of course.



  • OK, thanks for all the advice.  My logic (other than some simple logic for buttons and text fields and such) is in another package.  I'll start by moving all the dialog boxes to their own class, then I'll start maving each main screen to it's own class.   Let me just get this straight real quick though...  a single screen shouldn't be an instance of a JPanel but instead a class that extends JPanel.  Is that what you mean  by making the program OO?    thanks for the help (hope you enjoyed the WTF).



  • @tster said:

    Let me just get this straight real quick
    though...  a single screen shouldn't be an instance of a JPanel
    but instead a class that extends JPanel.  Is that what you
    mean  by making the program OO?




    Urgh, no.



    Proper object-oriented design means that each object represents a
    somewhat self-contained abstract entity that contains bot the data
    (fields) needed to represent its state and the functionality (methods)
    that operates on and uses that state. It should be possible to think
    about and use that object without thinking about (or even knowing) its
    implementation details. This higher level of abstraction is how OO
    programming makes it easier to build large systems.



    You want to be thinking at the highest possible level of abstraction at
    all times, and that also means to keep objects/classes themselves
    relatively simple, because otherwise you spend too much time worrying
    about complex interactions of implementation details. Instead of a
    huge, complex GUI class with many very simple fields (which is
    basically a procedural program with global variables) you want a
    moderately sized and simple one with fields that are themselves
    moderately sized classes and consist of a number of simple fields - or
    the hierarchy may go deeper. Good OO designs aren't necessarily
    hierarchical, but it makes sens for a GUI.



    OO design isn't something that can be expressed in hard rules you jsut
    have to follow, like "there must be inheritance" (actually, inheritance
    is often overused). It requires some intuition; it's a way of thinking.
    Once you've understood it, it just seems natural - simply put data and
    code together that belongs together.




  • OK I get it.  Now I see how companies can have lots of people working on one program.  we were having a hell of a time putting things together that we worked on seperately. 

    Thanks
    Tyler



  • @tster said:

    OK I get it.  Now I see how companies can have lots of people working on one program.  we were having a hell of a time putting things together that we worked on seperately. 


    Many IDEs are very comfortable as long as you work alone on a project, but make collaboration of many developers rather difficult.



  • @ammoQ said:

    @tster said:
    OK I get it.  Now I see how companies can have lots of people working on one program.  we were having a hell of a time putting things together that we worked on seperately. 


    Many IDEs are very comfortable as long as you work alone on a project, but make collaboration of many developers rather difficult.


    correct me if I'm wrong, but the IDEs integration with CVS repositories is suppose to make collaboration and integration smooth and easy. 



  • @tster said:

    @ammoQ said:
    @tster said:
    OK I get it.  Now I see how companies can have lots of people working on one program.  we were having a hell of a time putting things together that we worked on seperately. 


    Many IDEs are very comfortable as long as you work alone on a project, but make collaboration of many developers rather difficult.


    correct me if I'm wrong, but the IDEs integration with CVS repositories is suppose to make collaboration and integration smooth and easy. 

    This is correct, but not all IDEs support that resp. have supported that in the past out-of-the-box.



  • @ammoQ said:

    @tster said:
    @ammoQ said:
    @tster said:
    OK I get it.  Now I see how companies can have lots of people working on one program.  we were having a hell of a time putting things together that we worked on seperately. 


    Many IDEs are very comfortable as long as you work alone on a project, but make collaboration of many developers rather difficult.


    correct me if I'm wrong, but the IDEs integration with CVS repositories is suppose to make collaboration and integration smooth and easy. 

    This is correct, but not all IDEs support that resp. have supported that in the past out-of-the-box.

    Quite a lot of modern IDEs support integration well with CVS or (even better) SVN nowadays though (hell, you can even use SVN with Visual Studio through AnkhSVN).

    Now I'll concede that quite a lot of IDEs don't support every single SCM out of the box, but they often do via fairly easy to find plugins and stuff.



  • @tster said:

    Anyways our program has about 15 screens and lots (and lots) of dialog boxes.  we're not even half done with the GUI and the main view class is already approaching 10,000 lines.
    ...
     I've been thinking about putting all the dialog boxes in a seperate class but it seems like kind of a stupid hack.  Does anyone have advice or know what would be considered best practice here?


    Hmm I'm not quite sure how you have your dialog boxes implemented, if they are inner classes by all means move them out of the main class.

    On the topic of 'main classes' in general, I've had a similar problem with MFC and the main frame class. The problem being that the way message handling in MFC is done means that the 'natural' place to handle many messages is in the main frame. This can cause the class to get rather bloated. Moving the functionality out to other classes doesn't really work since most of the message handlers have little to do with any of the other message handlers, and moving them out to global functions doesn't usually work either since they are commonly GUI centered functions, so they just end up referencing the mainframe so much that they end up looking like a poorman's python member functions. :(
      I'd guess that this is a problem in most GUI applications?


Log in to reply