OK, then:
public static void setLayerNamesAsListData(LayerManager
argManager, JList argList) {
argList.setListData(argManager.getLayers().toArray());
}
I can cope with creating the utility method, just not the horrible
implementation.
Larry
On 9/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> 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
>
--
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
