Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 13 14 15 16 17 18 < 19 > 20 21 22 23 24 25 .. 166 >> Next

07
08 private String mailServer;
09 private String timecardServer;
10 private String userName;
11 private String ftpServer;
12
13
14 public PropertiesTest() {
15 }
16
17 [ GETTER AND SETTER METHODS FOR MEMBER VARIABLES... ]
18
19 public void storeProperties() {
20
21 Properties props = new Properties();
22
23 props.put("TIMECARD", getTimecardServer());
24 props.put("MAIL", getMailServer());
25 props.put("FTP", getFtpServer());
26: props.put("USER", getTimecardServer());
27
28 try {
29
30 props.store(new FileOutputStream("myProps.properties"), 2
"Properties");
31
32 } catch (IOException ex) {
33
34 ex.printStackTrace();
35
36 }
37
38 }
39
Listing 3.2 Storing user properties
Here is the example of the properties file that is produced:
#Properties
#Sun Feb 24 23:16:09 EST 2002
TIMECARD=time.mcbrad.com
FTP=ftp.mcbrad.com
USER=time.mcbrad.com
MAIL=mail.mcbrad.com
I Prefer Not to Use Properties 37
Instead, Listing 3.3 shows the same example with preferences:
package org.pitfalls.prefs;
import java.util.prefs.Preferences;
public class PreferencesTest {
private String mailServer; private String timecardServer; private String userName; private String ftpServer;
public PreferencesTest() {
}
[ GETTER AND SETTER METHODS FOR MEMBER VARIABLES... ]
public void storePreferences() {
Preferences prefs = Preferences.userRoot(); prefs.put("timecard", getTimecardServer()); prefs.put("MAIL", getMailServer()); prefs.put("FTP", getFtpServer()); prefs.put("user", getTimecardServer());
}
public static void main(String[] args) {
PreferencesTest myPFTest = new PreferencesTest(); myPFTest.setFtpServer("ftp.mcbrad.com"); myPFTest.setMailServer("mail.mcbrad.com"); myPFTest.setTimecardServer("time.mcbrad.com"); myPFTest.setUserName("Jennifer Richardson");
myPFTest.storePreferences();
}
Listing 3.3 Storing user preferences
Figure 3.1 shows the preferences stored, in this case, in the Windows Registry. Notice the slashes prior to each of the capital letters? This is due to the implementation on the Windows Registry, which does not support case-sensitive keys. The slashes signify a capital letter.
38 Item 3
Figure 3.1 Preferences stored in the Windows Registry.
So is the hierarchical nature of preferences the reason to use them instead of properties? While that is certainly a great reason, it is not the only reason. Properties files have no standardized way of placing configuration information within the filesystem. This means that you need a configuration file to find your configuration file! Furthermore, you must have a filesystem available, so a lot of devices cannot use the Properties API.
What about using JNDI? JNDI is a hierarchical structure. JNDI is a solid choice for maintaining information about users, applications, and distributed objects. Two things run against JNDI, however:
It doesn't give any indication of how the hierarchy is structured. Just because you can access the naming or directory service through JNDI doesn't give the information necessary to find the root of your specific context.
It can seem like driving a tack with a sledgehammer. JNDI requires a directory server to be available. Often the directory server is maintained by a separate organization, which may not see value in maintaining the fact that a guy named Marshall likes to have his email messages display their text in hot pink. No matter what your application, there is likely to be something that should be maintained in a more simple fashion.
Why not have a solution that handles properties in a hierarchical fashion and is independent of the back end storage mechanism? This is what the Preferences API gives you.
When Information Hiding Hides Too Much 39
Item 4: When Information Hiding Hides Too Much
When you are developing a framework that will be used by a large project, it is sometimes helpful to abstract the details of another API from the developers using your framework. For example, in an access control system, it may not be necessary to tell the users of your API that you are using database access control, directory server access control, or your own homegrown method of access control. Instead, you may simply hide the fact of what mechanism you are using and provide a public class (or interface) called AccessControl. When you write the implementation class, you will handle the mechanism of access control.
Many times, when API developers abstract the implementation of these classes, sometimes too much is abstracted where implementation-specific exceptions are involved. As an example, see Listing 4.1, which is an implementation of an access control mechanism with a Lightweight Directory Access Protocol (LDAP)-based directory server.
01 package 4; m e t i s l a LM t i p a v a m g. r o
02 import netscape.ldap.*;
03 public class AccessControl
04 {
05 private String m_host = null;
06 private int m_port = 389;
07 private int m_ldapversion = 3;
Previous << 1 .. 13 14 15 16 17 18 < 19 > 20 21 22 23 24 25 .. 166 >> Next