Code Design Question - "private static final String" and Methods

[Jordan D. Williams]

Hello everyone!

I am new to Java and I am designing a small calculator program that can solve equations. I ran into a situation regarding the design where I don't have enough experience to decide which would be the better solutions.

As with every program there will be text that will always get printed and the user will always see - such as a welcome screen, etc.

My program is designed to run in the console and once run it prints a description of the program, it grabs some information from an array about the different equation types that can be solved, etc, and finally asks the user to make a selection of which equation to solve. After the selection is made, it prompts for the required coefficients. Regardless of what equation type is selected some, at least one of those strings will always be presented to the user and it will never change. So what I thought was a good idea, and please correct me if I am wrong, was I created a class Messages, in which all the fields were private static final. Then I gave that class a private constructor so that it can't be initialized - since everything in there is static. Since both the fields and the constructor are private, I had to create "accessor" methods for each individual string or group of strings.

My idea was to create a central place for all strings that will appear in the program. So if someone types an invalid input, the sting will to tell the user the input was invalid will be here. Once the equation is solved and the system needs to print "The solution for x is: " the string will be in this class. My reasoning behind it was that I can then easily go back to one central location and change any string that is in the program, say if I had misspelled. What I didn't realize was that I can't input any sort of formatting within the strings themselves. So for example if I wanted the description to show up on 2 lines I would have to create 2 separate variables in the Messagesclass.

My question is three-fold:

1. Is it generally a good idea to keep all strings in the same place? Or should only the common strings that will always get printed be in a class such as this? Meaning - should I keep any messages that can be generated some method in the program be kept in that method, rather than in an outside class a private constructor?

2. Was declaring the fields private and creating public methods to get to those fields not a very bright idea? Should I just change all the fields to public, keep the constructor private, and get rid of the accessor methods? Or should I do something entirely different?

3. This might be OK for a small program since it has 20-30 strings. How would doing something like this impact a program that has thousands or tens of thousands of strings?

What I am looking for is "best practices" not just for this particular program but in general. I realize that it might have a lot to do with personal preference, but please do share those as well... And why you prefer doing it a certain way over another way.

Thanks for all your help!

[Jayesh A Lalwani]

It's good to keep all strings in one place. It's better to keep it in a resource file outside of your java class. It makes it easier to intertionalize your program. You can easily switch your language from English to say French by changing your resource file. ALso, it makes it easier for non-programmers to translate the file for you. Look at Resource Bundles to learn how to do this in Java

If you have final static variables that have to be used outside a class, the convention is to make them public. The reason why you want data members to be private is a) you want to hide data which makes it easier to change your implementation and b) you want to control access; ie; you want to control which classes can modify the member. Well, by definition static final members aren't extensible, and no one can modify them. So, there is no advantage in hiding the members behind methods. You might as well make them public.

[Jordan D. Williams]

Jayesh A Lalwani wrote:It's good to keep all strings in one place. It's better to keep it in a resource file outside of your java class. It makes it easier to intertionalize your program. You can easily switch your language from English to say French by changing your resource file. ALso, it makes it easier for non-programmers to translate the file for you. Look at Resource Bundles to learn how to do this in Java

If you have final static variables that have to be used outside a class, the convention is to make them public. The reason why you want data members to be private is a) you want to hide data which makes it easier to change your implementation and b) you want to control access; ie; you want to control which classes can modify the member. Well, by definition static final members aren't extensible, and no one can modify them. So, there is no advantage in hiding the members behind methods. You might as well make them public.

Hey Jayesh!

Great information! Thanks so much! I had read before a little bit about Android, ultimately that's the platform for which I want to develop, but I realize it's a bad idea to try to learn a specific platform for Java implementation without even understanding Java. Android programs keep all their strings in a separate file. I just never knew why. What you said makes perfect sense. Thanks for opening my eyes! Also thanks for referring me to the Internationalization article. Hopefully I can figure out how to do it. If not, I will be posting again .

Thanks again!

[Winston Gutkowski]

Jordan D. Williams wrote:3. This might be OK for a small program since it has 20-30 strings. How would doing something like this impact a program that has thousands or tens of thousands of strings?

Just to add to Jayesh's good advice: for very large numbers of messages you may want to think about storing them in a database.
For one thing, DB's such as JavaDB can actually be deployed with the application; for another, it makes you think about your messages as having a 'structure', just one example being the messages produced by a database like Oracle, which have (a) a unique ID and (b) a category (error, warning, information etc.).

Winston

[Jayesh A Lalwani]

Just to add one more thing:- Whether you put the messages in a property file or a database, they will have to be keyed. You will need a key to get to the message.
For example you will have a property file that says

welcome.message=Hello $user

The java code will need the keys to get to the message. You should put the keys in public static final variables

[Jordan D. Williams]

Hello everyone!

Sorry I took so long to post again...

Winston Gutkowski wrote:

Jordan D. Williams wrote:3. This might be OK for a small program since it has 20-30 strings. How would doing something like this impact a program that has thousands or tens of thousands of strings?

Just to add to Jayesh's good advice: for very large numbers of messages you may want to think about storing them in a database.
For one thing, DB's such as JavaDB can actually be deployed with the application; for another, it makes you think about your messages as having a 'structure', just one example being the messages produced by a database like Oracle, which have (a) a unique ID and (b) a category (error, warning, information etc.).

Winston

Thanks for the good advice Winston! I think still very far away from creating such a program, but good information is always useful. What would you say is a "very large number of strings"?

Jayesh A Lalwani wrote:Just to add one more thing:- Whether you put the messages in a property file or a database, they will have to be keyed. You will need a key to get to the message.
For example you will have a property file that says

welcome.message=Hello $user

The java code will need the keys to get to the message. You should put the keys in public static final variables

I am not sure I quite understand what you mean. The key is welcome.message. Is that correct? So if that is the "key" how do I pass it to System.out.print to print to the standard output. Additionally, what is $user? My guess is that it is some kind of a variable to identify the "user", but how do I pass that to the program so it gets printed with the string? I thought I can't have any variables in a properties file...

Here is one of the classes that I have, together with the implementation of the properties file.

DISCLAIMER: For those even newer than me (and I am very new), don't try to run the EquationSelector.java, it is not a functioning program and it is missing a main method.

EquationSelector.java

package com.nerdifier.equationsolver;

import com.nerdifier.utilities.Utils;
import java.util.ResourceBundle;

/**
 * This class is used to select the equation that the user wants to solve.
 * It also instantiates the appropriate object that needs to be created
 * based on the selection.
 * 
 * @param args 
 *          There are no available parameters.             
 */

public class EquationSelector {
    
    /**
     * A private constructor so no one can initialize the class.
     */
    
    private EquationSelector() {
        throw new UnsupportedOperationException(
                "Don't try to instantiate MyUtils class");
    }

    private static ResourceBundle res = ResourceBundle.getBundle(
            "com.nerdifier.equationsolver.resources.EquationSelector");
    
    // This gets the string introducing the available equation types
    private static String EQUATION_TYPES_TEXT = res.getString(
            "EQUATION_TYPES_TEXT");
    
    // This gets the simple equation type that will be passed to the array
    private static String SIMPLE_EQUATION = res.getString(
            "SIMPLE_EQUATION");
    
    // This gets the quadratic equation type that will be passed to the array
    private static String QUADRATIC_EQUATION = res.getString(
            "QUADRATIC_EQUATION");
    
    /*
     *  This is the array that will be used to calculate the available equation
     *  types and also print the available options to the console.
     */
    private static String[] EQUATION_TYPES = {
        SIMPLE_EQUATION, 
        QUADRATIC_EQUATION}; 
    
    
    private static void printEquationTypes() {
        System.out.printf("%s %n%n", EQUATION_TYPES_TEXT);
        // Iterates the contents of all indexes of the array EQUATION_TYPES
        for (int i = 1; i < (EQUATION_TYPES.length + 1); i++) {
            System.out.printf(i + ". %s %n", EQUATION_TYPES[i-1]);
        }
        /*
         *  Prints a new line to separate the input entry from the available
         *  selections.
         */
        System.out.println();
    }
    
    /**
     * This method asks the user for input from the keyboard and checks if it's 
     * an <tt>int</tt>. If it isn't then it prints an error message and asks
     * the user to try again. Once a valid selection is obtained, it checks it
     * against the valid selections based on the number of equations that the
     * is able to solve and if it is within the appropriate range, then the 
     * value is returned.
     */
    
    private static int equationSelector() {
        
        printEquationTypes();
        
        String EQUATION_SELECTOR_INSTR = res.getString(
                "EQUATION_SELECTOR_INSTR");
        String EQUATION_SELECTOR_PROMPT = res.getString(
                "EQUATION_SELECTOR_PROMPT");
        String EQUATION_SELECTOR_ERROR_NOT_INT = res.getString(
                "EQUATION_SELECTOR_ERROR_NOT_INT");
        
        System.out.printf("%s %n%n", EQUATION_SELECTOR_INSTR);
        
        int equationType = 0;
        while ((equationType < 1) || (equationType > EQUATION_TYPES.length)) {
            
            equationType = Utils.readIntFromIn(EQUATION_SELECTOR_PROMPT,
                  EQUATION_SELECTOR_ERROR_NOT_INT);
            
            if (equationType < 1 || equationType > EQUATION_TYPES.length) {
                String EQUATION_SELECTOR_ERROR_NOT_IN_RANGE = res.getString(
                        "EQUATION_SELECTOR_ERROR_NOT_IN_RANGE");
                System.out.printf("%n%s" + EQUATION_TYPES.length + ".%n%n", 
                        EQUATION_SELECTOR_ERROR_NOT_IN_RANGE);
            }
        }

        return equationType;
    }
    
    /**
     * Obtains the value for equationType.
     * 
     * @return
     *      Returns the value for equationType.
     */
    public static int getEquationType() {
        int equationType = equationSelector();
        return equationType;
    }
}

EquationSelector.properties

########################################################################
# File Name: EquationSelector.properties                               # 
#                                                                      #
# This file contains strings for the Equation selector class by        #
# Nerdifier.com                                                        #
#                                                                      #
# Author: Nerdifier.com                                                #
#                                                                      #
#                                                                      #
#   WARNING: DO NOT CHANGE THE CONTENTS OF THIS FILE OF THIS FILE      #
#   UNLESS YOU KNOW WHAT YOU ARE DOING. IF YOU DO, YOU RUN THE CHANCE  #
#   OF BREAKING THE PROGRAM AND YOU WILL HAVE TO DOWNLOAD IT AGAIN.    #
#                                                                      #
########################################################################

##################
# Equation types #
##################
EQUATION_TYPES_TEXT = You choose one of the following equation types:\u0020
SIMPLE_EQUATION = ax + b = c
QUADRATIC_EQUATION = ax^2 + bx + c = d
# more equation types to follow




##########################################
# Instructs the user to make a selection #
##########################################

EQUATION_SELECTOR_INSTR = Please enter the number corresponding to the \
                          equation you would like to solve.




#############################################################
# Prompts the user for a number to select the equation type #                          
#############################################################

EQUATION_SELECTOR_PROMPT = Enter a number:




#######################################################
# Error message when they user doesn't input a number #
#######################################################

EQUATION_SELECTOR_ERROR_NOT_INT = That is not a number. \
                                  Please enter a number:

#####################################################################
# This error message appears incomplete because the other number is #
# obtained by reading the length of an array via a method.          #
#####################################################################

EQUATION_SELECTOR_ERROR_NOT_IN_RANGE = The number you have entered is out of \
                                       range. Please enter a number that is \
                                       between 1 and\u0020

Does this look like a good implementation? Please, don't be afraid to tell me I am doing it all wrong if that's the case. it is my first try . I am sure there is something I can do to improve things. I don't know if it just looks like that to me, but the code itself doesn't seem very easy to read with all those variables.

Thanks for all your help!

[Winston Gutkowski]

Jordan D. Williams wrote:Thanks for the good advice Winston! I think still very far away from creating such a program, but good information is always useful. What would you say is a "very large number of strings"?

Dunno. How long is a piece of string?
Personally, I find anything more than 10 a pain, but there is the Alzheimer's to deal with....

Does this look like a good implementation? Please, don't be afraid to tell me I am doing it all wrong if that's the case. it is my first try...

I'd say: Not bad for a first cut; but a bit procedural. Your idea of a properties file is excellent though (it would have been my 2nd suggestion after a DB).

One of the ideas of Object-Orientation is to eliminate as much "dispatch code" as you possibly can (by which I mean code of the form:

if (something == this)
   doThis(); // or type == thisType
else if (something == that)
   doThat();
else if (something == theOther)
   doTheOther();
else
   throw new IDontKnowWhatTheHellYoureTalkingAboutException();

); and yours still seems to have quite a lot.

A couple things to think about:

What about a simple generic message parser that can plug in "parameterized" (ugh) values to a message in a similar way to an SQL PreparedStatement or String.format() (indeed, the latter may be an excellent way to write it). Whatever piece of code is actually displaying the message must know what it's displaying (because it has to know the key), and therefore what parameters to plug in.

The content of your messages would suggest that you want to support different types of "equation". I would definitely implement these as separate classes, with maybe an interface (Equation?) that ties them together.

HIH

Winston

[dennis deems]

Winston Gutkowski wrote:

Jordan D. Williams wrote:3. This might be OK for a small program since it has 20-30 strings. How would doing something like this impact a program that has thousands or tens of thousands of strings?

Just to add to Jayesh's good advice: for very large numbers of messages you may want to think about storing them in a database.
For one thing, DB's such as JavaDB can actually be deployed with the application; for another, it makes you think about your messages as having a 'structure', just one example being the messages produced by a database like Oracle, which have (a) a unique ID and (b) a category (error, warning, information etc.).

Winston

It's rare that I disagree with the advice Winston gives, but here I do. Text is notoriously volatile, because it can often be quite difficult to arrive at the desired wording. That's why larger companies tend to employ non-technical people who are good with words to take care of their text. The great thing about a properties file is that anyone who knows how to use a text editor can work with it. Storing messages in a database means that only someone with database access can modify the text. It also means that we can't monitor text changes via our regular version control. Deploying a database with your app just to handle text seems like cracking walnuts with a sledgehammer. What's the overhead compared to using the resource bundle?

[Winston Gutkowski]

Dennis Deems wrote:It's rare that I disagree with the advice Winston gives, but here I do. Text is notoriously volatile, because it can often be quite difficult to arrive at the desired wording. That's why larger companies tend to employ non-technical people who are good with words to take care of their text...What's the overhead compared to using the resource bundle?

Yes I see your point, but I think it does depend on the complexity of the text involved - particularly if there are any semantic rules or hierarchy.
I HATE (and I do mean HATE) XML; but I can see its uses for very large and complex configurations, and it's better for non-volatile stuff. To me, if you have several thousand messages that need maintaining you should write software to do it, not rely on the nous of a junior person who will probably be the scapegoat if anything naughty happens.

But, in the context of Jordan's program, you're probably right: a database is overkill.

Winston

[Jordan D. Williams]

Winston Gutkowski wrote:
...

I'd say: Not bad for a first cut; but a bit procedural...

...

A couple things to think about:

What about a simple generic message parser that can plug in "parameterized" (ugh) values to a message in a similar way to an SQL PreparedStatement or String.format() (indeed, the latter may be an excellent way to write it). Whatever piece of code is actually displaying the message must know what it's displaying (because it has to know the key), and therefore what parameters to plug in.

The content of your messages would suggest that you want to support different types of "equation". I would definitely implement these as separate classes, with maybe an interface (Equation?) that ties them together.

HIH

Winston

I have to agree with you on the code being procedural. I started with procedural languages and I am still trying to wrap my head around OOP. To be honest, I have absolutely no clue how to eliminate that code and make it more object oriented. On thing I should say, which I am not sure was clear from the code that I posted, is that this application has multiple classes. And yes, I have a class for each equation type and an Equation interface that implements a solve() method that takes varargs parameters so it can deal with different equations as necessary. I don't know if that clarification help my code look not-so-procedural .

I also have to say that the idea about a properties file was not mine. The idea was given to me by Jayesh A Lalwani in the second post of this thread. I had no idea the ResourceBundle class existed before that, so all credit goes to him about that one. I did do the research and figured out how to use it though .

The reason why I went with the ResourceBundle (I thought that a database might work, but I obviously had no idea how to implement that) was because, like Dennis Deems, pointed out, anyone can change the actual strings. My idea was to practice writing software in a way that is designed to be easily localized. I don't know if ResourceBundle is the best option, but I had to start somewhere.

As far as this goes:

Winston Gutkowski wrote: ... But, in the context of Jordan's program, you're probably right: a database is overkill.

I appreciate both your comments Winston and Dennis. While it might be an "overkill", for me it will most likely be good practice. I haven't dabbled with databases yet and I think I am still a ways away from that, but it is something I will have to learn.

I haven't finished writing the whole program yet, because every time I think I am done I find another hole in my code - which is good I guess, it helps me learn. First I wasn't validating the input, then I wasn't really validating the solutions, then I decided to "export" the text, now I am implementing the interface and reducing the "logic" in my main method... There is always something.

When I get it to a condition where I am satisfied with it, I will post a link and request a code review. I did that with the first version and I received a lot of positive comments on how it is looking. I was also given a ton of ideas on how to improve it, so the learning continues.

Thanks everyone for the great advise and taking the time to help someone else!

[Jordan D. Williams]

Winston Gutkowski wrote:

Dennis Deems wrote:It's rare that I disagree with the advice Winston gives, but here I do. Text is notoriously volatile, because it can often be quite difficult to arrive at the desired wording. That's why larger companies tend to employ non-technical people who are good with words to take care of their text...What's the overhead compared to using the resource bundle?

Yes I see your point, but I think it does depend on the complexity of the text involved - particularly if there are any semantic rules or hierarchy.
I HATE (and I do mean HATE) XML; but I can see its uses for very large and complex configurations, and it's better for non-volatile stuff. To me, if you have several thousand messages that need maintaining you should write software to do it, not rely on the nous of a junior person who will probably be the scapegoat if anything naughty happens.

But, in the context of Jordan's program, you're probably right: a database is overkill.

Winston

On another note... Why do you hate XML? Seems very useful and relatively simple to use.

[Winston Gutkowski]

Jordan D. Williams wrote:On another note... Why do you hate XML? Seems very useful and relatively simple to use.

I'll tackle this one first because it's easiest.

Because it's:
(a) Verbose
(b) Lengthy or hard-to-read - your choice.
(c) Ill-defined (specifically, in where to define "attributes"; or indeed, what they are).
(d) Basic; even with DTDs.
(e) The error messages...AARGH, I don't even know how to continue without violating the BeNice protocol. but, just for starters a few...
(e1) they're not not mandated (even with a DTD).
(e2) they're not contextual (there's no standard paradigm for even telling a user where the error occurred, let alone what the error was).

I won't go on (although I could). XML is a bastard son of a bastard son of something that was originally used for prettifying printer output back in the days when we used to call it "pyjama paper"; and has simply been "gussied up" with things like DTDs (interesting but, in the final analysis, useless).

It is NOT a language (I won't go into all the reasons here) - despite all the hype to the contrary - so unless someone actually makes it one (and I haven't seen any signs of it yet) it's only use is as a proprietary extension of HTML-style "structured" formatting.

And the only possible reason I could see for turning it into a language is so that we don't actually need to SEE the damn stuff again.

XML == Textual hammer. Something you can theoretically make things with, but without the nails or wood or rulers to make it happen without a programmer; and based on a medium that is (a) inefficient and (b) easily corruptible.

Phew. End of rant.

Does that answer your question? I'm starting to think that the first one might have been easier after all.

Winston

[Winston Gutkowski]

Jordan D. Williams wrote:I have to agree with you on the code being procedural. I started with procedural languages and I am still trying to wrap my head around OOP.

Don't sweat it. It took me close to 8 years (and two OO languages) before my "Eureka" moment, and I regard myself as reasonably intelligent. And a lot of the good procedural practises that you've (obviously) learned translate well to to OO programming, so your classes will probably be OK - just maybe not what they might be...yet.

To be honest, I have absolutely no clue how to eliminate that code and make it more object oriented.

Again, I think you've done most of the work already; but why don't you think about each of your Equation classes "understanding" what it's supposed to receive? It's a form of bottom-up programming - instead of some high level "manager" dealing with all the business of understanding what needs to be done, just hand off your String to an Equation object that "knows" what its supposed to get; if it doesn't, it it returns a "not understood" value. Yes, you could argue that it's still "dispatch" code, but its logic is very simple:
1. I've got a String.
2. I've got a bunch of Equations that know how to deal with Strings.
3. Try 'em out, in order of importance; first one gets.
Do you now see the importance of the interface? Such simple logic wouldn't be possible if you didn't have a way of holding a "bunch" of Equations.

And yes, I have a class for each equation type and an Equation interface that implements a solve() method that takes varargs parameters so it can deal with different equations as necessary. I don't know if that clarification help my code look not-so-procedural .

not at all. Sounds perfectly reasonable to me.

I also have to say that the idea about a properties file was not mine. The idea was given to me by Jayesh A Lalwani in the second post of this thread. I had no idea the ResourceBundle class existed before that, so all credit goes to him about that one. I did do the research and figured out how to use it though .

And well done for that. It's OK, Dennis was quite right: in your case a ResourceBundle is fine; it was me that was overthinking things.

My idea was to practice writing software in a way that is designed to be easily localized. I don't know if ResourceBundle is the best option, but I had to start somewhere.

Hey. Sounds good to me. Just keep in the back of your mind what you might need to do if any of those "locales" need to talk to each other. In procedural terms:
Don't burn any boats.

HIH. And good luck.

Winston

[Junilu Lacar]

Jordan D. Williams wrote:To be honest, I have absolutely no clue how to eliminate that code and make it more object oriented.

This might be a little too soon for you but the general process is called Refactoring. Here's the one in particular that you want to perform to eliminate the problem (aka "code smell") that Winston talked about: http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism. But then again, it doesn't look like you're a newbie programmer, just OO concepts, so it might make perfect sense to you when you read it.

[Jordan D. Williams]

Junilu Lacar wrote:

Jordan D. Williams wrote:To be honest, I have absolutely no clue how to eliminate that code and make it more object oriented.

This might be a little too soon for you but the general process is called Refactoring. Here's the one in particular that you want to perform to eliminate the problem (aka "code smell") that Winston talked about: http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism. But then again, it doesn't look like you're a newbie programmer, just OO concepts, so it might make perfect sense to you when you read it.

I am going to start with this... I should have been more clear when communicating my programming experience. I haven't actually programmed anything that I would consider "complicated" or "advanced". It's just that this is the first language that I try my hand at that is OOP. I have tried HTLM, Pascal (back in 1996!), and AutoIt, but I never really got to an "advanced" understanding or any of them. I will read what you suggested - not just that one part, but the whole website. It looks like there is a ton of useful, and unknown, to me information. Ahh... The more I dive into this Java thing, the more I realize how little I know. Sadly, it's a little discouraging sometimes, especially when I hear the experienced guys say something like:

Winston Gutkowski wrote: ... It took me close to 8 years (and two OO languages) before my "Eureka" moment, and I regard myself as reasonably intelligent. ...

But then I jump over to this forum and I get encouraged, because of how awesome and helpful everyone is here. So hopefully, it won't take me 8 years for the "Eureka" moment!

Winston Gutkowski wrote:
Phew. End of rant.

Wow... You really DO hate XML! Some of your reasoning I did not understand, but what I did understand sounds like big holes in their design.

Winston Gutkowski wrote:
3. Try 'em out, in order of importance; first one gets.

How exactly do I implement that? I know a little a bit about interfaces, but I am not sure I know how to do that... Specifically, how can I test if the "first" (most important) class can figure out if it "understands" what has been given to it? Do you mean by using a switch statement rather than the traditional procedural logic of if-then/if-then-else? By the way, all the equation classes will take double coefficients as parameters. And in the next version, maybe they will take BigDecimal as coefficients, since I have been lead to believe from other discussions on this forum that it's more precise that double. Is that correct?

Thank you both!

[J. Kevin Robbins]

Junilu Lacar wrote:Here's the one in particular that you want to perform to eliminate the problem (aka "code smell") that Winston talked about: http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism.

I just wanted to say thanks for that link. I've just spent the last two hours reading about anti-patterns and refactoring. Great site.

[Winston Gutkowski]

Jordan D. Williams wrote:

Winston Gutkowski wrote:3. Try 'em out, in order of importance; first one gets.

How exactly do I implement that? I know a little a bit about interfaces, but I am not sure I know how to do that... Specifically, how can I test if the "first" (most important) class can figure out if it "understands" what has been given to it?

Just have your solve() method return a value that is recognised as meaning "I don't understand this".

Alternatively (and probably even better), add a
boolean canSolve(String);
method to your Equation interface, whose sole purpose is to determine if the Equation "understands" the passed String.

Do you mean by using a switch statement rather than the traditional procedural logic of if-then/if-then-else?

Absolutely not. That's just dispatch code in a different form.

Basically, what you're doing at the moment is something like this:

List<Equation> myEquations;
String problem = ... // some equation string
Equation solver;
for (Equation eq : myEquations) {
   if (isQuadratic(problem) && eq instanceof Quadratic) {
      solver = eq;
      break;
   } else if (isQuartic(problem) && eq instanceof Quartic) {
      solver = eq;
      break;
   } else if ...
   // AARGH! :-)
}
return solver.solve();

whereas if you add the canSolve(String) method I suggested, each of your Equation types will "know" whether it can solve 'problem' or not, so:

for (Equation eq : myEquations) {
   if (eq.canSolve(problem)) {
      return eq.solve(problem);
   }
}

Job done. Your "Equation management" code (or class) doesn't need to know anything about the type of problem supplied; it simply needs to know how to find the right Equation to solve it. It's the job of the Equation class to "know" whether it can solve a particular problem or not.

Does that make it any clearer?

By the way, all the equation classes will take double coefficients as parameters. And in the next version, maybe they will take BigDecimal as coefficients, since I have been lead to believe from other discussions on this forum that it's more precise that double. Is that correct?

Oh yes. But at the cost of a fair bit of speed in some cases. Not that you should be worrying about that yet (see the words of Wulf below).

Winston

[Winston Gutkowski]

Jordan D. Williams wrote:Wow... You really DO hate XML! Some of your reasoning I did not understand, but what I did understand sounds like big holes in their design.

Well, to be fair to XML, it's probably less to do with it's design than it is to do with people using it for things that it was never intended for. Square pegs, round holes...

Winston

[Jordan D. Williams]

Winston Gutkowski wrote: ... if you add the canSolve(String) method I suggested, each of your Equation types will "know" whether it can solve 'problem' or not, so:

for (Equation eq : myEquations) {
   if (eq.canSolve(problem)) {
      return eq.solve(problem);
   }
}

Job done. Your "Equation management" code (or class) doesn't need to know anything about the type of problem supplied; it simply needs to know how to find the right Equation to solve it. It's the job of the Equation class to "know" whether it can solve a particular problem or not.

Does that make it any clearer?

...

Winston

I think I see what you are saying. Basically after I get the parameters of the equation - coefficients, exponents, etc... - I need to pass them to the canSolve method and method decides if can or cannot solve it. But if myEquations is a List of Strings how can account for the values of coefficients? Say I have in my list x^2 + x + 2 = 0. It's a quadratic equation. The QuadraticEquation.class can solve it. If the user types anything different than that, say 2x^2 + x + 2 = 0, then the canSolve method will return false for this. I would have to have some way of parsing it that will ignore white space, and somehow split the equation so it can isolate the variables and their exponents and the coefficients for those variables. Then it will have to parse all numbers from strings to their Types - all that so that the equation can be solved. Assuming that all I just said is even remotely correct, wouldn't that be doing exactly what Wulf warns about? (Not to mention that it will take me forever to figure it out )

In my design, I give the user the available options for equations. I basically have the program type on the screen all the equation types for which I can solve and ask the user to pick one. Based on that selection I have the GetCoeffs class collect the appropriate number of coefficients. I have a utility class that takes the input and checks it to make sure it's in the appropriate type - it's really a number and not a charor String. Once I have the coefficients from the user, I pass them to the appropriate class that can solve the equation - again based on that selection the user made in the beginning. ... OK when I write it out that way it does look like a lot like a switchboard...

I was thinking that maybe I can ask the user for the coefficients and the exponents first, but then I realized I have to ask them for the signs too (+, -, *, /) and that would look completely silly when I can just ask them for the String of the equation, which brings me back to first problem of having to create an algorithm for that one, I am sure it will be challenging for me, and two, I am not sure if it will be more "efficient" ... It will, however, be more Object Oriented, which is really the goal here. If it didn't have to be Object Oriented, why would I use an OO language when I can use any procedural language that has a basic way for input/output and basic math.

What to you think? (I hope my "question" is somewhat clear)

Thanks!

[Junilu Lacar]

Well, you have to choose the way you want your users to provide input. Seems to me the design choice to have the user select an equation type is good. Then you either let them type in the whole equation and then parse it against the pattern of the equation type (RegEx will probably be your best option for implementing this) or you can just have them enter the coefficients appropriate for the equation type. It's one or the other. Or you can have the user choose a way. It helps to sketch out scenarios and how you want the human-computer interaction to proceed.

*** Equation Solver, version 1.0 ***

Please select the type of equation you would like to solve:
1. Simple
2. Quadratic
Your choice (enter a number) ==> 1

You have chosen to solve a SIMPLE EQUATION

Please select from these options:
1. I want to enter coefficients only
2. I want to enter the equation myself
Your choice (enter a number) ==> 1

You have chosen to enter coefficients only:
... and so on

You don't have to ask the user to enter the coefficient's sign separately. Negative numbers can be parsed out of Strings that start with "-" and no sign is the same as a positive sign.

[Winston Gutkowski]

Jordan D. Williams wrote:... OK when I write it out that way it does look like a lot like a switchboard...

Good. Now you're starting to think like an OO programmer...

Like I said before, you've actually done quite a lot of the work already, and there's absolutely nothing wrong with your selector.properties idea - it's very sensible; particularly if you want your program to figure out the right type of Equation to solve a problem simply passed as a string (and Junilu's idea of a regex is a very good one).

The main problem is in your "selection management" code. As I said above, it shouldn't need to know anything about what problem has been passed to it, merely how to find the right Equation, whether that's with a simple dialog, viz:

Computer: What type of equation would you like to solve?

User: I'd like to solve a Quadratic please.

or by the user entering a string and an Equation figuring out that it's the right one for the job.

Let's take the first (a dialog), because it's by far the easiest:
Add a
public Equation getValues();
method to your Equation interface. The business of this method is to prompt the user for the relevant values, and return an Equation object of the correct type primed with the supplied values and ready for a call to solve().
Each Equation implements this method according to the rules for its own type (and that's where your properties file might come in useful).

The procedure would then go something like this:

1. Management code asks the user to choose a type of equation:

2. User selects the one they want.

3. Management code gets the correct type of Equation (lets say a Quadratic) from some internal List or array:
Equation e = equations[value-for-quadratic]; (don't forget, Quadratic is an Equation)

4. Management code then calls getValues() for the type, which returns a new Quadratic object primed with those values:
e = e.getValues();
This might produce a dialog like:

Please enter value for a: 4

Please enter value for b: 3

Please enter value for c: -1

5. Management code then calls
e.solve();
which produces something like:
The solutions for 4x^2 + 3x - 1 = 0 are: (whatever).

If you follow me so far, let me know and we can go on to the slightly trickier canSolve() → solve() idea.

Winston

[Jordan D. Williams]

Hello again!

Thanks Junilu for the ideas about RegEx. I have heard of it, but I have never used it and I don't really know what it does, but I am definitely going to check it out and see what I can do.

Winston Gutkowski wrote: If you follow me so far, let me know and we can go on to the slightly trickier canSolve() → solve() idea.

This is actually precisely what the first version of the program did. The reason why I started rewriting it from the ground up was to, of course practice, but also to make it more "universal". I am not sure that is the correct word. I wanted to try my hand at "Internationalization" with the properties file and I wanted to make my code more "reusable".

(I will post a link with the complete source code for this first version later)

The way I had it before was like this:

1. Ask the user what type of equation they want to solve.
2. Ask them to enter the appropriate coefficients based on the selection.
3. Based on their selection, have a switch routine that will creates the appropriate Object that knows how to solve the equation.
4. Print the solutions.

I believe this can be referred to as "dumb" code. I didn't have Interfaces and I didn't have constructors. My code had no "logic" of it's own. It was completely inflexible. There was absolutely no code reuse and really what I did in several class files could have been combined in one huge mess of one file and accomplish the same thing since most of my methods were static so I can access them in the way that I was used to with procedural code. If I wanted to add a new equation type to be solved that needed more coefficients, I would have had to add another coefficient "getter" method, because the way in which I got coefficients was very inflexible. I had a method that asked for 2 coefficients, the another method that is copy/past of the first one and then just add another couple of lines in order to get the 3rd coefficient.

I simply hadn't figured out that with OOP languages, at least with Java, you can write flexible code that can figure things out on it's own - like your suggestion for a canSolve method. What the next version of the code will attempt to do (I have another thread for my code review here) is be a lot more flexible.

This is how I plan on having it work:

1. Ask the user what type of equation they want to solve.
1.1. Check to make sure they have made a valid selection.
2. Ask them to enter the appropriate coefficients based on their selection using a CoeffGetter.class that can get any number of coefficients based on the selection in 1. (So if I wanted to add another equation type to be solved I could just add it to the ArrayList of equations and I wouldn't need to modify the CoeffGetter.class at all - hence code reuse).
2. 1. Check to make sure they have entered a number.
3. Write the coefficients to an array.

I am basically done with this part. For the next part I have a few options:

OPTION 1:
I can have each separate equation type in it's own class and have a varargs interface that is implemented in each equation type class. Then based on the equation type that was selected in one, instantiate the appropriate object and have a constructor to which the coefficients from the array created in 3 are passed. Then solve the equation and use another method (or class) that uses a loop to print the appropriate number of solutions (so that I will not have to change that method/class when I add more equation types).

OPTION 2:
I can have a single class that is the equation solver. I can have the array from 3 be static so that I can access it from methods inside this equation solver class. I can have code in the initialization that checks the length of the coefficients array (or use the information from the equation selection in 1) and thereby decide which of the overloaded methods to run. If I am not using the right term, please correct me. Overloaded method, if I am not wrong, are methods with the same name, but take different number of paramenters. Ex: solve( int a, int b); and solve( int a, int b, int c);. The appropriate method will them take the coefficients, solve the equation, and have the other method/class print the solutions.

OPTION 3:
What you suggested: canSolve() → solve(). Well, maybe for your suggestion to work I will have to modify the 1-3 steps .

That's what I am thinking. Basically I wanted to rewrite the code in such a way that it would be relatively easy to maintain the code and to add functionality. I just realized how FAR off the original topic this is going .

[Winston Gutkowski]

Jordan D. Williams wrote:The way I had it before was like this:

1. Ask the user what type of equation they want to solve.
2. Ask them to enter the appropriate coefficients based on the selection.
3. Based on their selection, have a switch routine that will creates the appropriate Object that knows how to solve the equation...

Right, but it's that switch part that's the problem. Rather than have the management code worry about all that stuff, let the equation class do it.

Perhaps a piece of code will help. It only includes relevant code for a Quadratic class:

public interface Equation {
   public double solve();
   public Equation getValues();
}

public final class Quadratic
   implements Equation
{
   /**
    * A Quadratic with all values set to NaN (not a number).
    * Useful only as a "type" template for calling getValues().
    */
   public static final TEMPLATE = new Quadratic();

   private final double a;
   private final double b;
   private final double c;

   private Quadratic() {
      a = b = c = Double.NaN;
   }

   private Quadratic(double a, double b, double c) {
      this.a = a;
      this.b = b;
      this.c = c;
   }

   public final Equation getValues() {
      Scanner s = new Scanner(System.in);
      System.out.println("Please enter value for a:");
      double a = s.nextDouble(); // assume this to include all required validation code
      System.out.println("Please enter value for b:");
      double b = s.nextDouble();
      System.out.println("Please enter value for c:");
      double c = s.nextDouble();
      return new Quadratic(a, b, c);
   }

   public final double solve() {
      // returns the result for this Quadratic
      // (ignore for the moment the fact that there are two)
   }
}

public class Manager {
   private static Equation[] equations = new Equation[] {
      Quadratic.TEMPLATE,
      Quartic.TEMPLATE,
      ...
   };
   private static int usersChoice;
     
   public static void main(String[] args) {
      // dialog to ask user to choose a type of equation
      // which is put into 'usersChoice'
      Equation type = equations[usersChoice];
      type = type.getValues();
      System.out.println("Solution=" + type.solve());
   }
}

Do you see what's happened? There isn't a single 'if' statement anywhere in the management code because it relies on each Equation class knowing not only how to solve a problem, but also what parameters it's supposed to get and how to get them. This (if you're still awake), is polymorphism in action.

Let me know if you still don't understand the difference between the above and what you had in mind. It could be that I've misconstrued something.

Winston

[Winston Gutkowski]

Jordan D. Williams wrote:...using a CoeffGetter.class that can get any number of coefficients...

I just read this bit, and there's absolutely no problem with that, apart from it possibly being difficult to create custom prompts (and that's where your selector.properties file might help), but again, all Quadratic.getValues() needs to do is call that class's method, viz (from above):

public final Equation getValues() {
   double[] coeffs = CoeffGetter.getCoeffs(3);
   return new Quadratic(coeffs[0], coeffs[1], coeffs[2]);
}

Make sense?

Winston

[Jordan D. Williams]

Winston Gutkowski wrote:

Jordan D. Williams wrote:...using a CoeffGetter.class that can get any number of coefficients...

I just read this bit, and there's absolutely no problem with that, apart from it possibly being difficult to create custom prompts (and that's where your selector.properties file might help), but again, all Quadratic.getValues() needs to do is call that class's method, viz (from above):

public final Equation getValues() {
   double[] coeffs = CoeffGetter.getCoeffs(3);
   return new Quadratic(coeffs[0], coeffs[1], coeffs[2]);
}

Make sense?

Winston

Yes, it does make total sense. I also understand the difference between what I was doing and what you were showing me in the example albeit I don't quite understand how it all works. I guess I could later on have the EquationSelector class to just get a number from the user and have the Manager decide if it can solve().

I have to say that looking at your example code blew my mind. It took me about an hour to understand what was going on in there. I am not even sure I understand it all. Could you explain, or give me e reference, a little bit about that whole TEMPLATE thing? And how can the Manager class have an equations field of type Equation that is an array? You don't have to define that first in some way? Can I create an array of any object type just like int[] and String[]? Although I guess it does make sense since String is actually an object and you can have String[] arrays. I guess I always thought that you can do that because it was defined in java.lang.String...

So forgetting that I don't quite understand how that works for a minute, let me say what I 'think' is happening in the manager class. Oh wait... I think I KNOW what happens!!!

Basically the manager class, when instantiated creates an array of that contains values of type Equation and references the TEMPLATE field in each equation type, that in turn is a reference to instantiate an object of that give equation type? That is why the TEMPLATE filed is static - it has to be accessible from outside the class, without have an object instantiated first. TEMPLATE is public since it has to be visible to the Manager class. We don't want anyone to be able to change the value of it since it will break the program. Therefore you also make the TEMPLATE field final. What confuses me is that you never instantiate the Manager calss?! Did you just forget to instantiate it? I highly doubt that! ... The other thing that confuses me is how can you reference a field inside of a class and then have it instantiate an object of the same class? Is it because it is static final (static making it a class field rather than a instance field, and final making it immutable and thereby making it [arguably] a unique field)?

Clearly I have a lot to learn about pretty much everything . I have read a couple of books, but I didn't really get much from them. I learned enough to be able to learn more basically... I should have started with the Java Tutorials, which is what I am going through now.

Thanks for all your time that you are investing in me, Winston (and everyone else!). I really appreciate it.

By the way.. I am on Eastern Standard Time (UTC -05:00)

[Winston Gutkowski]

Jordan D. Williams wrote:I have to say that looking at your example code blew my mind. It took me about an hour to understand what was going on in there.

I think you may be getting close to your "Eureka" moment

Could you explain, or give me e reference, a little bit about that whole TEMPLATE thing? And how can the Manager class have an equations field of type Equation that is an array?

Arrays can be of any type you want, including another array. Think about int[][]. It may look like a 2D array, but what it is in fact is an array of arrays.

As for the TEMPLATE, it was just the easiest way I could think of to return a "dummy" object for the type. It could just as easily have been a static method; or indeed the management code could just have created a dummy object itself (new Quadratic(0, 0, 0)?). I kind of like hiding constructors from clients though, because that way you can make sure that your objects are created properly.
There may well be better (ie, clearer) techniques out there too. To be honest, it's one of those times when you wish you could define static methods in an interface, because it would be nice to be able to enforce the "template" strategy on all Equations, but without using something like a Factory pattern (you'll find out about patterns later), it'd be quite difficult.

Basically the manager class, when instantiated creates an array of that contains values of type Equation and references the TEMPLATE field in each equation type, that in turn is a reference to instantiate an object of that give equation type? That is why the TEMPLATE field is static - it has to be accessible from outside the class, without have an object instantiated first. TEMPLATE is public since it has to be visible to the Manager class. We don't want anyone to be able to change the value of it since it will break the program. Therefore you also make the TEMPLATE field final.

10/10.

What confuses me is that you never instantiate the Manager calss?! Did you just forget to instantiate it? I highly doubt that! ...

No; although at my age Alzheimer's does rear its ugly head now and again.
Basically, the presence of the main() method allows it to be called from the command line, viz:
java [-jar whatever] Manager
and it gets automatically loaded by the JVM. You'll also notice that most of the stuff in it is static. It was just an example (and looking at it now, I could have picked a better name, like EquationSolver).

The other thing that confuses me is how can you reference a field inside of a class and then have it instantiate an object of the same class? Is it because it is static final (static making it a class field rather than a instance field, and final making it immutable and thereby making it [arguably] a unique field)?

Spot on. It's probably worth mentioning that you shouldn't do the same thing with instance fields.

Thanks for all your time that you are investing in me, Winston (and everyone else!). I really appreciate it.

No probs. That's what we're here for; and it's particularly nice for us when
(a) people listen.
(b) they start to "get it"; and it sounds like you are.

So, just to recap:
1. Keep on the lookout for "dispatch code". If you find yourself writing it, STOP, and think how you might be able to do it some other way.
2. Classes should be responsible for everything they define, which in the case of your Equation includes:
(a) Accepting/validating parameters.
(b) (possibly) Understanding the type of problem it can solve.

And just one final thing: there are plenty of ways to skin most cats. What I've given you is just one possibility, and it may well not be the best. What it does do though is make use of some of the power offered by Java classes.

By the way.. I am on Eastern Standard Time (UTC -05:00)

Daylight I hope; everybody else is.

I'm on BST (Belgian Summer Time (UTC +02:00)), so I guess we'll just have to keep an eye out for messages.

Winston

[Jordan D. Williams]

Winston Gutkowski wrote:
I think you may be getting close to your "Eureka" moment

Oh I hope you are right!

To be honest, it's one of those times when you wish you could define static methods in an interface, because it would be nice to be able to enforce the "template" strategy on all Equations, but without using something like a Factory pattern (you'll find out about patterns later), it'd be quite difficult.

I have actually heard of design patterns. Junilu Lacar referenced this site and it talks about all kinds of things like ULM design, design patterns, refactoring, etc. It's not Java specific, and it's a bit too advanced for me right now, but it's a great source of information.

Basically, the presence of the main() method allows it to be called from the command line, viz:
java [-jar whatever] Manager
and it gets automatically loaded by the JVM.

Would that also work if I compile/run in Eclipse? Everything I have read so far only talks about the main() method being executed at launch.

No probs. That's what we're here for; and it's particularly nice for us when
(a) people listen.
(b) they start to "get it"; and it sounds like you are.

Well, '(b)' might take a while, but given enough time I would like to believe that anything can get through my thick, procedurally brainwashed mind!

So, just to recap:
1. Keep on the lookout for "dispatch code". If you find yourself writing it, STOP, and think how you might be able to do it some other way.
2. Classes should be responsible for everything they define, which in the case of your Equation includes:
(a) Accepting/validating parameters.
(b) (possibly) Understanding the type of problem it can solve.

And just one final thing: there are plenty of ways to skin most cats. What I've given you is just one possibility, and it may well not be the best. What it does do though is make use of some of the power offered by Java classes.

Daylight I hope; everybody else is.

Yep!

I'm on BST (Belgian Summer Time (UTC +02:00)), so I guess we'll just have to keep an eye out for messages.

It's really called Belgian Summer Time? That's awesome! Sounds 'fun'! Here.. meh... It's just 'Standard' time... Nothing special about it! ;)

And yes, definitely will look out for messages. I am originally from Bulgaria so I am familiar with the time zone.

Thanks again for everything. I will post the code with your implementation as soon as I have it ready... It might take a while!

[Winston Gutkowski]

Jordan D. Williams wrote:I have actually heard of design patterns. Junilu Lacar referenced this site and it talks about all kinds of things like ULM design, design patterns, refactoring, etc. It's not Java specific, and it's a bit too advanced for me right now, but it's a great source of information.

Indeed. Junilu knows his stuff.

And I would advise you not to forget all the good rules you've (obviously) learnt from your procedural languages. Most of them still apply in an OO context; it's just you have to learn a few new ones too.

For example: You may have heard of the "page of code" rule - if you find you're writing more than a "page" (≈40-50 lines; or a screenful; or 7±2 actions) of code to do something, try and see if you can break it down further (ie, into other methods). Well, in the case of an OO language, you may also want to think if you can break it out into a class.

And as far as this particular example is concerned, try and understand the difference between the way you were thinking about the problem and the way I was. In OO-land, classes and objects aren't just passive "things" that we "do stuff to"; they're active participants in their own life-cycle, actions and events. And they contain knowledge.

If you're interested, I'd be happy to send you a copy of my 'Eureka moment diary' (and it truly was a 'Eureka' moment - and those don't happen often in a lifetime). Just send me a private message and I'll zap it off (it's just a Word doc). The best I can tell you at the moment is that sometimes you need to "turn logic upside-down" - and all I really mean by that is trying to view it from the object's point-of-view, not your code's.

Would that also work if I compile/run in Eclipse? Everything I have read so far only talks about the main() method being executed at launch.

Yup. I use Eclipse, and I do it all the time for writing test classes.

Well, '(b)' might take a while, but given enough time I would like to believe that anything can get through my thick, procedurally brainwashed mind!

Read this. Easily the best page on the subject I know of. And don't be discouraged by it: what it's trying to say is that you have time. Nobody's going to expect you to "get it" overnight. Like I say, it took me 8 years - although I may have been a bit more brainwashed than you - but every single second was worth it; and I suspect it may make me a more "rounded" OO programmer now than some newbie who's never had to deal with anything but an OO language.

Thanks again for everything. I will post the code with your implementation as soon as I have it ready... It might take a while!

You're welcome. Look forward to seeing it.

Winston

[Mike Simmons]

Jordan D. Williams wrote:

Winston Gutkowski wrote:I'm on BST (Belgian Summer Time (UTC +02:00)), so I guess we'll just have to keep an eye out for messages.

It's really called Belgian Summer Time? That's awesome! Sounds 'fun'! Here.. meh... It's just 'Standard' time... Nothing special about it! ;)

Actually, no one uses Eastern Standard Time right now. You are using Eastern Daylight Time - what we call daylight saving, they call summer time. For programmers, it's useful to be aware of the distinction.

[Winston Gutkowski]

Mike Simmons wrote:

Jordan D. Williams wrote:

Winston Gutkowski wrote:I'm on BST (Belgian Summer Time (UTC +02:00)), so I guess we'll just have to keep an eye out for messages.

It's really called Belgian Summer Time? That's awesome! Sounds 'fun'! Here.. meh... It's just 'Standard' time... Nothing special about it! ;)

Actually, no one uses Eastern Standard Time right now. You are using Eastern Daylight Time - what we call daylight saving, they call summer time. For programmers, it's useful to be aware of the distinction.

However, as pointed out in a different thread, the timezone (and also the java.util.TimeZone) is actually Eastern Standard Time. It just happens to use daylight savings (ie, it's a rule). My suspicion is that, if Java allows both, they're actually aliases, although that's theoretically wrong.

Winston

[Mike Simmons]

Mmm, I contend that the time zone is not actually Eastern Standard Time; it's the Eastern Time Zone. Java's library is misleading in what they call the "display name" here, and they should really fix the documentation to point out that it is not at all suitable as a display name if you're in DST. The overloaded method that includes "boolean daylight" is necessary in order to get something useful.

[Winston Gutkowski]

Mike Simmons wrote:Mmm, I contend that the time zone is not actually Eastern Standard Time; it's the Eastern Time Zone. Java's library is misleading...

You may be right, but I fear that history, mnemonics and the 'Net are against you (your own link refers to a page called 'Eastern_standard_time'). The name "Eastern Time Zone" is totally ambiguous anyway, unless you're entirely US-centric (and don't forget that "proper" time was invented by us Brits, starting with "railway time" ).

I'm also pretty sure that the official designation in the TZ libs is 'EST'.

Winston

[Mike Simmons]

Winston Gutkowski wrote:

Mike Simmons wrote:Mmm, I contend that the time zone is not actually Eastern Standard Time; it's the Eastern Time Zone. Java's library is misleading...

You may be right, but I fear that history, mnemonics and the 'Net are against you (your own link refers to a page called 'Eastern_standard_time').

I kept that intentionally so you could see that Wikipedia redirects a query for "eastern standard time" to "Eastern Time Zone" - see the "redirected from" text? You can link more directly with http://en.wikipedia.org/wiki/Eastern_Time_Zone if you like.

Winston Gutkowski wrote:The name "Eastern Time Zone" is totally ambiguous anyway

Sure, as is Eastern Standard Time. Or names like Central Time or Mountain Time. Even Pacific Time is problematic, though it at least sounds more specific, but isn't really.

Winston Gutkowski wrote:unless you're entirely US-centric

We also allow Canuckians to use those time zone names. They get a few extras too.

Winston Gutkowski wrote:I'm also pretty sure that the official designation in the TZ libs is 'EST'.

If you do TimeZone.getTimeZone("EST"), you get a TimeZone that (a) also identifies itself as "Eastern Standard Time", but (b) does not indulge in any daylight savings nonsense. Because, ahem, that wouldn't be EST, would it?

The docs do correctly warn against using those three-letter codes, since there's ambiguity whether (for example) CST should be Central Standard Time, or China Standard Time. (Ignoring the further ambiguity about "central".) They don't address the further (and IMO worse) ambiguity from people who request "EST" without knowing what that actually means, and expect it to use DST. Actually as I recall some of these TimeZones did sometimes return DST in the past, but that appears to be fixed.

Java time libraries really need a canonical list of the best ways to identify time zones. People generally just guess at the time zone id, and get one that seems to work, until it doesn't. I usually use the ones like "America/New_York" or "Europe/Paris", as they seem the most complete and unambiguous. But that stuff should be documented somewhere in the Java API.

[Winston Gutkowski]

Mike Simmons wrote:

Winston Gutkowski wrote:I'm also pretty sure that the official designation in the TZ libs is 'EST'.

If you do TimeZone.getTimeZone("EST"), you get a TimeZone that (a) also identifies itself as "Eastern Standard Time", but (b) does not indulge in any daylight savings nonsense. Because, ahem, that wouldn't be EST, would it?

Actually, I was referring to the tz libs as installed with most Unixes, which I believe Java uses a variant of (most likely a subset, because they also contain historical data, such as British East Africa Time (GMT + 2:45) ). It's been a while since a looked at them (11 years actually), but as I recall the records do include DST information, along with the mnemonic used when it's in force (eg, EDT for EST).

The docs do correctly warn against using those three-letter codes, since there's ambiguity whether (for example) CST should be Central Standard Time, or China Standard Time. (Ignoring the further ambiguity about "central".) They don't address the further (and IMO worse) ambiguity from people who request "EST" without knowing what that actually means, and expect it to use DST.

Don't know if I agree with you there: Time zones are geographic. DST is simply an implementation (usually national policy, but not always; check out Saskatchewan time), so it seems to me that if you're going to key on anything, it should be the base time zone (which is the way tz does (or at least did) it), and that base time zone should contain information about any DST/regional variants.

Also, as you say, people are familiar with 'EST' as a mnemonic. Do you know the mnemonic for "Eastern Time"? There is one, and it looks suspiciously like a tz record key to me. Seems to me that splitting hairs like that (even if "correct") is going to cause more problems than it solves, particularly as it's not consistent. 'WET' does use daylight savings, despite the fact that in the summer it's called WEST, which isn't even recognized by java.util.TimeZone.

I suspect that some standardized form of mnemonic + country/province code (ISO 3166-2?) might help, but I don't see any sign of it yet. And then of course you have the EU...and the fact that some places are thinking of moving to permanent summer time...

Thorny problem for an old normalizer like me.

Winston

[EDIT]: Sorry Mike, couldn't resist this: What do you get when you execute
TimeZone.getTimeZone("EST5EDT").getDisplayName()?

[Junilu Lacar]

I've heard a lot of talk about Joda Time lately. Maybe it's time (excuse the pun) to check it out.

[Winston Gutkowski]

Junilu Lacar wrote:I've heard a lot of talk about Joda Time lately. Maybe it's time (excuse the pun) to check it out.

I have, and it's great; but I'm not sure that even it sorts out the TZ issues. Good old Saskatchewan time...I still remember it from when I used to work in Vancouver.

Winston

[Winston Gutkowski]

PS: Sorry Jordan, we've got totally off-topic here.

Winston

[Jordan D. Williams]

Winston Gutkowski wrote:PS: Sorry Jordan, we've got totally off-topic here.

Winston

@Mike: Thanks for pointing out that this is something I need to keep in mind. I haven't really dabbled with time in Java yet, but it's never early to learn something useful!

No problem at all. I try to read as much as I can from this forum. This thread or another... It doesn't really matter to me.

By the way I did read your 'Eureka' moment paper and I am sorry, but I will have to disappoint you... Most of it went over my head! . I can't really go into details about that now, since I am pressed by time, but soon...

[Winston Gutkowski]

Jordan D. Williams wrote:By the way I did read your 'Eureka' moment paper and I am sorry, but I will have to disappoint you... Most of it went over my head! . I can't really go into details about that now, since I am pressed by time, but soon...

Fine, I'd be glad of any comments. It was written when I was in the "new flush of Euekadom".

Probably best to send me a private message (or, even better, e-mail me).

Winston

[Mike Simmons]

Winston Gutkowski wrote:

Mike Simmons wrote:The docs do correctly warn against using those three-letter codes, since there's ambiguity whether (for example) CST should be Central Standard Time, or China Standard Time. (Ignoring the further ambiguity about "central".) They don't address the further (and IMO worse) ambiguity from people who request "EST" without knowing what that actually means, and expect it to use DST.

Don't know if I agree with you there: Time zones are geographic.

Well, time zones may be geographic (mostly), but a TimeZone (the Java class we were discussing) is definitely a set of rules based on a combination of geography and politics.

Winston Gutkowski wrote:DST is simply an implementation (usually national policy, but not always; check out Saskatchewan time),

Or Arizona. Excluding the Navajo nation, but including the Hopi nation, which is completely surrounded by the Navajos. Definitely, there are exceptions at levels other than national.

Winston Gutkowski wrote:so it seems to me that if you're going to key on anything, it should be the base time zone (which is the way tz does (or at least did) it), and that base time zone should contain information about any DST/regional variants.

I agree that we should key on the base zone in some way, but I disagree that "EST" should be considered an acceptable way to refer to that base zone. The 'S' actually is useful for something - namely distinguishing between DST and non-DST. In my opinion, it should never be used for the general case which may or may not be in DST. That just negates the usefulness of the term.

Winston Gutkowski wrote:Also, as you say, people are familiar with 'EST' as a mnemonic. Do you know the mnemonic for "Eastern Time"?

"America/New_York", as far as I'm concerned.

I agree that we need good mnemonics for time zones. That doesn't mean we should misapply well-known mnemonics to mean something they don't.

Winston Gutkowski wrote:There is one, and it looks suspiciously like a tz record key to me.

Which are you thinking of?

Winston Gutkowski wrote:Seems to me that splitting hairs like that (even if "correct") is going to cause more problems than it solves, particularly as it's not consistent.

In my experience use of "Standard Time" to differentiate from "Daylight Time" is pretty consistent - among people who know what they're talking about. Not as the name of a time zone, but as a description of what a given time actually means. "09:30 AM EST" and "09:30 AM EDT" mean different things, and most systems that display such things use them correctly. If they don't, that's usually a sign that they are set up incorrectly, and will probably give an off-by-one-hour error when you next cross a DST boundary.

Maybe it may seem like splitting hairs when talking about EST vs EDT, as one can generally figure out what was intended - since no one uses EST in summer. But elsewhere, the distinction is more important. Arizona uses Mountain Standard Time, exclusively. When the rest of its "time zone" switches to DST in summer, that means those other states are using Mountain Daylight Time, while Arizona still uses Mountain Standard Time. Anyone taking a time given as Mountain Standard Time and applying DST to it is wrong, period. Those well-defined terms are useful for distinguishing what a time actually means.

Winston Gutkowski wrote:'WET' does use daylight savings, despite the fact that in the summer it's called WEST, which isn't even recognized by java.util.TimeZone.

Well, I don't know what the normal European usage is here, but this doesn't really seem like a problem to me. Because none of W, E or T stands for Standard or anything which implies Not DST. So if "WET" refers to a policy that sometimes uses DST, that seems fine to me. Aside from the fact that anyone who reads the JavaDoc for TimeZone should avoid using the three-letter abbreviations anyway.

Winston Gutkowski wrote:[EDIT]: Sorry Mike, couldn't resist this: What do you get when you execute
TimeZone.getTimeZone("EST5EDT").getDisplayName()?

Just what we'd both expect. Yes, getDisplayName() continues to give a misleading answer here, just as I said in my first post in this thread. There are multiple TimeZone instances that claim to be "Eastern Standard Time", yet obey different rules, so saying that this is the name of the time zone doesn't really help anything. The ID is at least unique (within the Java libs), even if it's sometimes misleading. But we definitely could use better identifiers, both inside and outside the Java ecosphere.