Prev: JNI win32 and Layered windows.
Next: Urgent Opening for Senior .Net Engineer position with our direct client in Milpitas, CA
From: markspace on 16 Mar 2010 23:50
Rhino wrote:

> I'd be delighted to get some guidance on the best way to handle this
> sort of situation.


I didn't read all the replies to this carefully, so apologies if I
repeat something.

First, I notice a general trend in the Java API to separate the
interface from the utility methods that operate on it. For example:

Collection - An interface.
Collections - Utility methods that operate on Collection.

Executor - An interface.
Executors - Utility methods that operate on Executor.

So I think you should follow the same pattern. Declare your interface
and utility methods in two separate places. It makes it much easier for
anyone trying to read your documentation at least, not to have too much
stuff crammed onto one Javadoc page.

WebSafeColor - interface.
WebSafeColorUtils - utilities go here.


> Since the Map of web-safe Colors is effectively immutable - the 216
> colors have been defined and there aren't going to be any additions or
> deletions to the list - it seems reasonable to put them in a some kind

Yeah right. Go read Sun's tutorial web page on enums. Sun used the
planets of the solar system as an example, because there's no way that
the planets could ever change! Until the astronomers declassified Pluto
as no longer being a planet, and the list did change. Never never rely
on some other source to be constant. It'll trip you up, some how.

Plus, as another coder, there's no way I want to see a dry list of 216
static class instantiations in a code listing.

This strikes me as a perfect place for a resource file. Define a text
file like this:

# Web Safe Colors
# file: web_safe_colors.txt
Black : 0 0 0
White : 255 255 255
Green : 0 255 0
Red : 255 0 0
Blue : 0 0 255
# etc.

Then read this in. You can use the Properties class to do it in one shot:

Properties colors = new Properties();
colors.load(getClass().getResourceAsStream("web_safe_colors.txt"));

Now you have to iterate over these properties to make a map of colors
rather than just string properties, but I'd much rather read this, which
should be about a 5 line loop, than a big old list of class
constructors. Also, if you can download the list of colors from some
source, you should be able to use a decent editor to regex and massage
the file into a Java properties format, thereby reducing wear and tear
on your finger tips, and reducing the chance of typos in entering the
list values too. Win win.

Just my 2 nickels here.


From: markspace on 16 Mar 2010 23:52
Kevin McMurtrie wrote:

> Consider a situation where the design starts out using Enum but later
> needs to load definitions from a configuration file. That can't be done
> with Enum, EnumMap, or code that works with them. The original poster
> mentioned having large sets of definitions of Colors so I think a design
> using Enum would run into future problems.


I didn't read this before I posted, but it echoes my own concerns exactly.
From: RedGrittyBrick on 17 Mar 2010 06:48
On 17/03/2010 01:47, Lew wrote:

> Java programming with types rides the synergy of interfaces and generics
> to build solid code.

Gosh, have you been reassigned to a certain other department?

http://www.dilbert.com/strips/comic/2007-09-18/

--
RGB
From: Rhino on 17 Mar 2010 16:28
On Mar 16, 10:50 pm, markspace <nos...(a)nowhere.com> wrote:
> Rhino wrote:
> > I'd be delighted to get some guidance on the best way to handle this
> > sort of situation.
>
> I didn't read all the replies to this carefully, so apologies if I
> repeat something.
>
> First, I notice a general trend in the Java API to separate the
> interface from the utility methods that operate on it.  For example:
>
> Collection - An interface.
> Collections - Utility methods that operate on Collection.
>
> Executor - An interface.
> Executors - Utility methods that operate on Executor.
>
> So I think you should follow the same pattern.  Declare your interface
> and utility methods in two separate places.  It makes it much easier for
> anyone trying to read your documentation at least, not to have too much
> stuff crammed onto one Javadoc page.
>
> WebSafeColor - interface.
> WebSafeColorUtils - utilities go here.
>
>  > Since theMapof web-safe Colors is effectively immutable - the 216
>  > colors have been defined and there aren't going to be any additions or
>  > deletions to the list - it seems reasonable to put them in a some kind
>
> Yeah right.  Go read Sun's tutorial web page on enums.  Sun used the
> planets of the solar system as an example, because there's no way that
> the planets could ever change!  Until the astronomers declassified Pluto
> as no longer being a planet, and the list did change.  Never never rely
> on some other source to be constant.  It'll trip you up, some how.
>
> Plus, as another coder, there's no way I want to see a dry list of 216
> static class instantiations in a code listing.
>
> This strikes me as a perfect place for a resource file.  Define a text
> file like this:
>
> # Web Safe Colors
> # file: web_safe_colors.txt
> Black : 0 0 0
> White : 255 255 255
> Green : 0 255 0
> Red : 255 0 0
> Blue : 0 0 255
> # etc.
>
> Then read this in.  You can use the Properties class to do it in one shot:
>
>    Properties colors = new Properties();
>    colors.load(getClass().getResourceAsStream("web_safe_colors.txt"));
>
> Now you have to iterate over these properties to make amapof colors
> rather than just string properties, but I'd much rather read this, which
> should be about a 5 line loop, than a big old list of class
> constructors.  Also, if you can download the list of colors from some
> source, you should be able to use a decent editor to regex and massage
> the file into a Java properties format, thereby reducing wear and tear
> on your finger tips, and reducing the chance of typos in entering the
> list values too.  Win win.
>
> Just my 2 nickels here.

I see we think in the same ways. I too would have thought of trying to
find an external source of the websafe colors online somewhere and
then have a program to turn it into the properties file and then load
it. I'm skeptical about whether such a source exists though. I can
imagine a source for the websafe colors themselves - I saw them listed
on a few different websites, each time in a different format - but
none of the colors I saw had names assigned to them, except the
Visibone chart at http://www.visibone.com/colorlab/big.html. I don't
see how I can get both the names and the colors from that page since
the chart seems to be generated by JavaScript. For now, I'll probably
just hard-code the properties file directly and put the rest on my "To
Do - Eventually" list..... ;-)

Let's say that I follow the rest of your advice though and make do
with a Properties file to contain the WebSafeColors. I'm not sure what
the WebSafeColor interface would contain and what would be in the
WebSafeColorsUtils class. And when I generate ColorSets, would they
use both or just the WebSafeColorUtils?

I really it's probably hard to sketch those out in any detail at this
point but whatever you can do would help me get a clearer idea of what
goes where and how to use it.

--
Rhino
From: Lew on 17 Mar 2010 22:41
Lew wrote:
>> Java programming with types rides the synergy of interfaces and generics
>> to build solid code.

RedGrittyBrick wrote:
> Gosh, have you been reassigned to a certain other department?
>
> http://www.dilbert.com/strips/comic/2007-09-18/

Are you suggesting that Java programming with types does not ride the synergy
of interfaces and generics to build solid code?

--
Lew
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: JNI win32 and Layered windows.
Next: Urgent Opening for Senior .Net Engineer position with our direct client in Milpitas, CA