Larry, Maybe I am totally missing something with my programming style. I will try to explain my reasoning for wanting this in a separate method, and then you can correct whatever bad programming habits that appear. :]
First of all, I really try to avoid chaining method calls like you have done in your suggestion, especially in the argument list for a method. (I know experienced programmers are likely screaming at my stupidity at this point.) I do this because I believe it makes the code much more difficult to understand. I know it is more concise, and it may even be more efficient at run time, but these are not my first goals when I write source code for a program like OpenJUMP. (These chained method calls, which Jon loves, were one of my main obstacles to understanding JUMP's source code.) I really beleive the key to OpenJUMP's survival is not speed, efficiency, or even concise code. I beleive the key to OpenJUMP's survival is the ease with which OpenJUMP users and non-programmers can learn what is going on in the source code. We need to convert these users to programmers if we want to maintain a strong developer community. This effort to produce "understandable code" means that I try to use lots of source code comments, and I try to never chain method calls. As an example, what you wrote as: argList.setListData(argManager.getLayers().toArray()); I would write as: Collection layers = argManager.getLayers(); Object[] layersAsArray = layers.toArray(); argList.setListData(layersAsArray); Now, one reason I always look for room to create "utility methods" is so I can have concise code without the confusing side effects. So my three statements become: DialogUtil.setLayerNamesAsListData(); This allows me to be concise and the programmer reading my code can look at the setLayerNamesAsListData() method to understand my logic if he still needs to. It also allows me to add Javadoc comments to the method, which I wouldn't have been able to do if the logic was embedded in the class file. Here is another reason why I prefer a utility method for this scenario: What happens when we decide to modify the behavior of the getLayers() method? (Maybe we modify it to return an Iterator instance, or maybe we have it return an array directly.) I don't want to track down all of the instances of "argList.setListData(argManager.getLayers().toArray());" in all of my source code. With my technique I can just modify the DialogUtil.setLayerNamesAsListData(); method. I know this type of change isn't likely in OpenJUMP's source code, but I never know what changes future requirements or improvements might bring. Utility methods insulate my code from these types of changes by isolating the number of times I have to deal with them. It is important to remember that my point of view is somewhat skewed. I am not a professional programmer. I hadn't written one line of source code until I started using JUMP, and it is the only reason I learned Java. Even though I program for other reasons now, I always try to write my source code to be read and understood by someone just beginning to look "inside the box". The Sunburned Surveyor On 9/18/07, Larry Becker <[EMAIL PROTECTED]> wrote: > Why don't you just do: > > argList.setListData(argManager.getLayers().toArray()); > > and skip the whole method. > > Larry > > On 9/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > I have attached my implementation of the setLayerNamesAsListData > > method. I was thinking about placing this method in Sigle's DialogUtil > > class. > > > > Someone asked to see my implementation, and I didn't want to cloud up > > the other thread, which has moved onto other topics. > > > > The Sunburned Surveyor > > > > P.S. - Did we decide if the DialogUtil class is the appropriate place, > > or should I put it into a separate JAR? > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > > -- > http://amusingprogrammer.blogspot.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
