Replies to This Discussion

Permalink Reply by Juan Rolando Reza on February 5, 2012 at 4:16pm

Paul,

OMG 2000 SLOC !

 

Here are some thoughts for you.

The first most important concept to guide your design is "Separation of Concerns". More on that in a moment.

For your application, the "concerns" should be chosen within the MVC design pattern (Model View Controller).

Within Separation of Concerns, you should use encapsulation which is not possible if everything is in one big class.

Finally, an informal rule of thumb. No, rules of thumbs:

   * Classes should be small; small enough so that if you were working in a team, programmers would be unlikely to want to check out and edit the same classes for their different narrowly focused tasks.

   * Classes should be individually testable, or in small groups conveniently testable.

   * Don't wait. Start creating classes as part of an application's vision or design; not after you code a big GUI-does-everything. Make your "concerns" specific. They are not only concerns like "hello, I am the UI concern" or "hello, I'm the process flow". These are good. But try to be more granular. "hi, I verify that values are valid in this case", "hi, I do all data IO for projector luminosity", etc. I'm just tossing out some thoughts here.

   * A final rule-of-thumb may or may not pertain to your application. This is the anticipation that certain "business rules" or interfaces to projection/play-back equipment will change from one "generation to another". I will have some more to say about this another time because of an article I have submitted to an IEEE conference titled, the Generatrix Design Pattern.

 

Also, in addition to decomposing your prototype into a bunch of maintainable classes, you should use a small hierarchy instead of keeping numerous classes in the same directory. This makes great use of the default (package) visibility of classes. In effect, classes within a package have appropriate necessary visibility to each other by not other such packages. It's a beautiful thang.

 

By the way, your question is quite synchronistic. I visited the Planetarium show yesterday for the first time here in Tallahassee and intend to join the local astronomy club. I'm interested in the technology whereby multiple amateur astronomers can merge their images to simulate a huge ground-based tele.

 

Hope this helps.

 

• ▶ Reply

Permalink Reply by Ngadjeu on February 5, 2012 at 4:49pm

I can advise you to follow the rules of project management and conception.une class of more than 2000 lines too big or me c it should probably not meet the compliances of OOP.So seen from the rules of how OOP burst this class and make small classes interconnectedby rules of inheritance, and other ...

• ▶ Reply

Permalink Reply by Patrick Kay on February 6, 2012 at 9:50am

Paul,

I don't know the exact layout of your app, but for me it's a tradeoff between having a few long files versus many smaller ones.  I don't like having to sort through 12 files to trace the flow of my code, but a long file can be a pain too.  The IDE's features (I use Eclipse) can help with long files with it's expand/collapse of methods, etc.

One approach I've used with MVC is to have a general controller for the entire app that delegates to "sub-controllers".

For example, let's say your app is called PlanetCon (Planetarium Control).  Then assume you have tabs for logging in, manipulating lights and setting options.  I would have a PlanetConController.java as my main controller.  It would delegate to a LoginController.java, LightingController.java and a OptionsController.java.

• ▶ Reply

Permalink Reply by John Considine on February 6, 2012 at 12:58pm

There are plugins that can be used for the IDE that will give you warnings about code getting too large among other things.  It comes set with default parameters which are descent.  The one we use is called CheckStyle and it works for Eclispe.  I am not sure what plugins are available for Net Beans but I am sure they have them for that. 

 

There is a book by Martin Fowler title Refactoring Improving The Design Of Existing Code published by Addison Wesley that covers in detail the questions you asked.  Some of you may recall when Martin was at the Orlando JUG about 10 years ago.  Mike, can you get him to come back?

 

The above book gives you guidelines on how to determine when to break up code and how to refactor code that has not been broken up yet. 

• ▶ Reply

Permalink Reply by Juan Rolando Reza on February 6, 2012 at 7:51pm

Patrick, others, ...

If you enjoy Eclipse as much as I do, I hope y'all have a chance to use it on a nice large display such as the iMac 27inch.

It increases your options for class size and how you sort through them. I can code according to what is appropriate to the purpose of a class rather than the incidental constraints of my view area. I recently had a chance to the iMac. I used 6 source tabs (simultaneously showing source for 6 different classes) and many lines. Mix and match the vertical and horizontal splits plus lots of space for console, variables, etc. Thank you Steve Jobs.

• ▶ Reply

Permalink Reply by Paul Stearns on February 6, 2012 at 9:24pm

I will definitely take a look at the book you recommended.  I saw that it has pretty high reviews on Amazon.

I am still learning my way around NetBeans and will keep an eye out for any plugins like the one you mentioned.  I choose NetBeans because it was the first IDE that I downloaded.  I was also able to get something happening pretty quickly as far as creating my GUI.  I just finished a video tutorial from Lynda.com that used Eclipse.  The tutorial was very helpful is showing what Eclipse could do, but I did not see anything on creating a GUI layout.  I also tried to import my NetBeans project into Eclipse and did not have any luck.  Not sure if that is even a good idea if I was successful.

Thanks.

John Considine said:

There are plugins that can be used for the IDE that will give you warnings about code getting too large among other things.  It comes set with default parameters which are descent.  The one we use is called CheckStyle and it works for Eclispe.  I am not sure what plugins are available for Net Beans but I am sure they have them for that. 

 

There is a book by Martin Fowler title Refactoring Improving The Design Of Existing Code published by Addison Wesley that covers in detail the questions you asked.  Some of you may recall when Martin was at the Orlando JUG about 10 years ago.  Mike, can you get him to come back?

 

The above book gives you guidelines on how to determine when to break up code and how to refactor code that has not been broken up yet. 

• ▶ Reply

Permalink Reply by Paul Stearns on February 6, 2012 at 9:35pm

After I posted the question I did try to remove some of my code to create a separate class file, but I must not have gotten all the pieces necessary because I ended up with lots of errors.  Got a little frustrated and went back to what I had.  I have a deadline coming up and I just want to get the functions working.  It is not a huge mess, yet.

The GUI currently has 4 tabs.  The first one controls a groups of lights with buttons for fade up and down.  There are also sliders that the user can use to adjust levels.  The 3 remaining tabs have some of the same controls, but they also have more controls for the different lighting effects available.  These tabs are identical in there functionality, but they control separate effects banks.  I thought I could pull out each of the effects banks to create smaller code segments, but again I did not do it right and was faced with many errors.

I also want to try and pull out the code that opens my socket connection to the Ethernet to RS-232 converter, but am not sure what I need to do there either.

Patrick Kay said:

Paul,

I don't know the exact layout of your app, but for me it's a tradeoff between having a few long files versus many smaller ones.  I don't like having to sort through 12 files to trace the flow of my code, but a long file can be a pain too.  The IDE's features (I use Eclipse) can help with long files with it's expand/collapse of methods, etc.

One approach I've used with MVC is to have a general controller for the entire app that delegates to "sub-controllers".

For example, let's say your app is called PlanetCon (Planetarium Control).  Then assume you have tabs for logging in, manipulating lights and setting options.  I would have a PlanetConController.java as my main controller.  It would delegate to a LoginController.java, LightingController.java and a OptionsController.java.

• ▶ Reply

Permalink Reply by Michael Levin on February 7, 2012 at 1:38pm

John, It would be great to have Martin Fowler back to give another presentation at the OrlandoJUG. You never know, maybe we'll get lucky and he'll volunteer again! Best, Mike

John Considine said:

There are plugins that can be used for the IDE that will give you warnings about code getting too large among other things.  It comes set with default parameters which are descent.  The one we use is called CheckStyle and it works for Eclispe.  I am not sure what plugins are available for Net Beans but I am sure they have them for that. 

 

There is a book by Martin Fowler title Refactoring Improving The Design Of Existing Code published by Addison Wesley that covers in detail the questions you asked.  Some of you may recall when Martin was at the Orlando JUG about 10 years ago.  Mike, can you get him to come back?

 

The above book gives you guidelines on how to determine when to break up code and how to refactor code that has not been broken up yet. 

• ▶ Reply

Permalink Reply by Jackie Gleason on February 10, 2012 at 5:02pm

The best advice I can give you is to opensource your code in Github and ask for feedback :-)

• ▶ Reply

▶ Reply to Discussion