This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
In my project, I don't have something like that. Whenever you can just put the constant in the appropriate class. For example, I have default socket port number and I put it in the class that used by the server to listens for the connection.
hope that helps.
Jeffry Kristianto Yanuar Java Instructor SCJP 5.0 SCJA SCJD (Working on UrlyBird 1.3.2) --> testing and documenting the assignment
I think this is a bad idea, because it is not particular Object Oriented.
Consider the following case: you have a constant related to your server, the default port number for sockets for example. If you now decide to remove the entire "SocketServer" because you want an "RMIServer", you would have to look all the constants of the "SocketServer" up in the Constants class. This could easily be forgotten when redesigning your project thereby leaving unused constants in your class.
Encapsulate your Enums and Constants in a package or a class where applicable. If you have global constants, put it in a common package or project that all other projects depend on. [ September 06, 2008: Message edited by: arulk pillai ]
Thanks for all the feedback, I don't wan't to lose unnecessary marks due to this approach not being OO compliant so I am going to declare and use the constants in the classes were they are going to be used.
Though from a maintainability stand point, as a developer I would rather have constants declared in one class and know that if I am required to change a constant value which could be the same in multiple classes, due to a requirement change, I can change it in one class and not have to search and change the constant in multiple classes.
If you want a container for constants, an interface will do just as well. I use this quite a lot for handling XML, in a way that I have an interface bearing constants for the element and attribute names specified by a given XML schema. All classes dealing with instance documents of the XML schema now can import the corresponding interface and have the constants for the element and attribute names at hand.
Joined: Jul 22, 2008
Originally posted by Devon Richards: Though from a maintainability stand point, as a developer I would rather have constants declared in one class and know that if I am required to change a constant value which could be the same in multiple classes, due to a requirement change, I can change it in one class and not have to search and change the constant in multiple classes.
You should still declare a constants which is used by multiple classes only once: in the class where it originates from, or where it is used the most. It is a very bad idea to have the same constant declared in multiple classes.