Placement of Constants
in [Java Help]
|
From: Rhino on 23 May 2010 21:15 I'm really hoping this will be a straightforward non-controversial question (for a change) on my part ;-) I am doing a code review on some code that I want to put in a "code portfolio" so I'm trying to figure out the best ways to do various things. Specifically, I have about 20 classes right now in the main part of the project that I'll be putting in the portfolio. There are a substantial number of constants used in one place or another. I have _most_ of them in a single class that is called FooConstants (where "Foo" is replaced by the name of my project.) FooConstants has a private constructor that throws UnsupportedOperationException (as suggested previously in this group) and everything else in it is a static final, i.e. a constant. Is there any reason NOT to put _all_ of the constants used throughout the project in FooConstants? Or is it wiser to only move something to a XXXConstants class if it is used in more than one class? For instance, if I have a constant named FOO_FILE_NAME and it is used only in class FooBlahBlah, is it better to leave the constant in FooBlahBlah rather than forcing developers to have to go to another class to determine (or change) its value? Or is it better to have all constants, wherever used, all together in FooConstants? Am I safe in assuming that if a Constant is used in more than one class and it is supposed to have the same value in each case, that I definitely want those constants centralized in my FooConstants class? Otherwise, if I put a unique occurrence of each multiply-occuring constant, like FOO_LOG_PATH, in each class where it occurs, it seems to be almost inevitable that FOO_LOG_PATH will eventually have different values in each of the classes where it is used. -- Rhino --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: markspace on 23 May 2010 21:32 Rhino wrote: > Is there any reason NOT to put _all_ of the constants used throughout the > project in FooConstants? Or is it wiser to only move something to a > XXXConstants class if it is used in more than one class? I would do the opposite: move constants out of FooConstants and into classes that are closer to where they belong conceptually or are consumed. For example, JFrame.EXIT_ON_CLOSE (from memory, didn't compile check that) gets used a lot in many of my applications, and indeed all over the place in Swing applications in general. Does Sun put EXIT_ON_CLOSE in a separate SunConstants class? Nope, the keep EXIT_ON_CLOSE close to where it belongs and where it is used (consumed). This makes more sense as applications grow larger. Can you imagine what the size of SunConstants would be if Sun actually put every constant in their API in that class? Yuck. It would be a nightmare to document or read. So it's probably better that the constants relating to the JFrame API are in the JFrame class, where you'd expect to find them, and expect to see them documented. Just my 2 cents here.
From: Arne Vajhøj on 23 May 2010 21:38 On 23-05-2010 21:15, Rhino wrote: > I'm really hoping this will be a straightforward non-controversial question > (for a change) on my part ;-) > > I am doing a code review on some code that I want to put in a "code > portfolio" so I'm trying to figure out the best ways to do various things. > > Specifically, I have about 20 classes right now in the main part of the > project that I'll be putting in the portfolio. There are a substantial > number of constants used in one place or another. I have _most_ of them in > a single class that is called FooConstants (where "Foo" is replaced by the > name of my project.) FooConstants has a private constructor that throws > UnsupportedOperationException (as suggested previously in this group) and > everything else in it is a static final, i.e. a constant. > > Is there any reason NOT to put _all_ of the constants used throughout the > project in FooConstants? Or is it wiser to only move something to a > XXXConstants class if it is used in more than one class? > > For instance, if I have a constant named FOO_FILE_NAME and it is used only > in class FooBlahBlah, is it better to leave the constant in FooBlahBlah > rather than forcing developers to have to go to another class to determine > (or change) its value? Or is it better to have all constants, wherever > used, all together in FooConstants? > > Am I safe in assuming that if a Constant is used in more than one class and > it is supposed to have the same value in each case, that I definitely want > those constants centralized in my FooConstants class? Otherwise, if I put a > unique occurrence of each multiply-occuring constant, like FOO_LOG_PATH, in > each class where it occurs, it seems to be almost inevitable that > FOO_LOG_PATH will eventually have different values in each of the classes > where it is used. XxxxConstants with constants is not a very good pattern. I would definitely move the constants to the classes where they logical belong. Typical the class that has methods that expects those constants as input. Also use enum instead of int constants for additional type safety when possible. For configuration stuff then use a configuration file for flexibility. If it is a simple case then good old Properties class should be sufficient. Filenames and directories belong to the last category. Arne
From: Lew on 23 May 2010 21:43 Rhino wrote: > Specifically, I have about 20 classes right now in the main part of the > project that I'll be putting in the portfolio. There are a substantial > number of constants used in one place or another. I have _most_ of them in > a single class that is called FooConstants (where "Foo" is replaced by the > name of my project.) FooConstants has a private constructor that throws > UnsupportedOperationException (as suggested previously in this group) and > everything else in it is a static final, i.e. a constant. It's silly to throw that exception in the private constructor. Only the class itself can invoke the constructor. I prefer a private constructor with an empty body. "static final" is not the same as a "constant variable" in Java. A constant can be non-static, and a final can be non-constant. > Is there any reason NOT to put _all_ of the constants used throughout the > project in FooConstants? Or is it wiser to only move something to a > XXXConstants class if it is used in more than one class? Depends. Probably not wise to put them all in one place - some constants (or static finals) should be private, not public, ergo kept in the class where they're used. Tightly coupling classes together is a bad idea often. Like everything else, you have to do what makes sense. Some constants should be in a project-wide class, sure. Others in a functional unit, for example, data-access constants in a data-access utility class. Others should be package-private. Some should be protected or private, for use only in an inheritance hierarchy or the class itself, respectively. You have to think each choice through. Access should be as wide as needed but not wider, and as narrow as possible but not narrower. > For instance, if I have a constant named FOO_FILE_NAME and it is used only > in class FooBlahBlah, is it better to leave the constant in FooBlahBlah > rather than forcing developers to have to go to another class to determine > (or change) its value? Or is it better to have all constants, wherever > used, all together in FooConstants? I usually put static finals generally, and constants particularly, as private in the class where they're needed, and give them wider access only when needed as needed. YAGNI. > Otherwise, if I put a > unique occurrence of each multiply-occuring constant, like FOO_LOG_PATH, in > each class where it occurs, it seems to be almost inevitable that > FOO_LOG_PATH will eventually have different values in each of the classes > where it is used. Logging is usually configured in an external resource, like the log4j.properties file for the log4j framework. -- Lew
From: Rhino on 24 May 2010 00:50
markspace <nospam(a)nowhere.com> wrote in news:htckvq$k5g$1(a)news.eternal-september.org: > Rhino wrote: > >> Is there any reason NOT to put _all_ of the constants used throughout >> the project in FooConstants? Or is it wiser to only move something to >> a XXXConstants class if it is used in more than one class? > > > I would do the opposite: move constants out of FooConstants and into > classes that are closer to where they belong conceptually or are > consumed. > > For example, JFrame.EXIT_ON_CLOSE (from memory, didn't compile check > that) gets used a lot in many of my applications, and indeed all over > the place in Swing applications in general. Does Sun put > EXIT_ON_CLOSE in a separate SunConstants class? Nope, the keep > EXIT_ON_CLOSE close to where it belongs and where it is used > (consumed). > > This makes more sense as applications grow larger. Can you imagine > what the size of SunConstants would be if Sun actually put every > constant in their API in that class? Yuck. It would be a nightmare > to document or read. So it's probably better that the constants > relating to the JFrame API are in the JFrame class, where you'd expect > to find them, and expect to see them documented. > > Just my 2 cents here. I hadn't thought of the issue the way you present it. You make a lot of good points. Thanks Markspace! -- Rhino --- news://freenews.netfront.net/ - complaints: news(a)netfront.net --- |