为什么需要使用单例模式 属性是系统的一种"资源"，应当避免有多余一个的对象读取非凡是存储属性。此外，属性的读取可能会在很多地方发生，创建属性对象的地方应当在哪里不是很清楚。换言之，属性治理器应当自己创建自己的实例，并且自己向系统全程提供这一事例。因此，属性文件治理器应当是一个单例模式负责。
系统设计 系统的核心是一个属性治理器，也就是一个叫做ConfigManager 的类，这个类应当是一个单例类。因此，这个类应当有一个静态工厂方法，不妨叫做getInstance()， 用于提供自己的实例。
为简单起见，本文在这里采取"饿汉"方式实现ConfigManager 。例子的类图如下所示。
本例子的源代码如下所示。
代码清单6：ConfigManager 的源代码
import java.util.Properties;
import java.io.FileInputStream;
import java.io.File;
public class ConfigManager
{
/**
* 属性文件全名
*/
private static final String PFILE =
System.getProperty("user.dir")
+ File.Separator + "Singleton.properties";
/**
* 对应于属性文件的文件对象变量
*/
private File m_file = null;
/**
* 属性文件的最后修改日期
*/
private long m_lastModifiedTime = 0;
/**
* 属性文件所对应的属性对象变量
*/
private Properties m_props = null;
/**
* 本类可能存在的惟一的一个实例
*/
private static ConfigManager m_instance =
·234·Java 与模式
new ConfigManager();
/**
* 私有的构造子，用以保证外界无法直接实例化
*/
private ConfigManager()
{
m_file = new File(PFILE);
m_lastModifiedTime = m_file.lastModified();
if(m_lastModifiedTime == 0)
{
System.err.println(PFILE +
" file does not exist!");
}
m_props = new Properties();
try
{
m_props.load(new FileInputStream(PFILE));
}
catch(Exception e)
{
e.printStackTrace();
}
}
/**
* 静态工厂方法
* @return 返还ConfigManager 类的单一实例
*/
synchronized public static ConfigManager
getInstance()
{
return m_instance;
}
/**
* 读取一特定的属性项
*
* @param name 属性项的项名
* @param defaultVal 属性项的默认值
* @return 属性项的值（如此项存在）， 默认值（如此项不存在）
*/
final public Object getConfigItem(
String name， Object defaultVal)
{
long newTime = m_file.lastModified();
// 检查属性文件是否被其他程序
// （多数情况是程序员手动）修改过
// 假如是，重新读取此文件
if(newTime == 0)
{
// 属性文件不存在
if(m_lastModifiedTime == 0)
{
System.err.println(PFILE
+ " file does not exist!");
}
else
{
System.err.println(PFILE
+ " file was deleted!!");
}
return defaultVal;
}
else if(newTime > m_lastModifiedTime)
{
// Get rid of the old properties
m_props.clear();
try
{
m_props.load(new FileInputStream(PFILE));
}
catch(Exception e)
{
e.printStackTrace();
}
}
m_lastModifiedTime = newTime;
Object val = m_props.getProperty(name);
if( val == null )
{
return defaultVal;
}
else
{
return val;
}
}
}
在上面直接使用了一个局域的常量储存储属性文件的路径。在实际的系统中，读者可以采取更灵活的方式将属性文件的路径传入。
读者可以看到，这个治理器类有一个很有意思的功能，即在每一次调用时，检查属性文件是否已经被更新过。假如确实已经被更新过的话，治理器会自动重新加载属性文件， 从而保证治理器的内容与属性文件的内容总是一致的。
怎样调用属性治理器 下面的源代码演示了怎样调用ConfigManager 来读取属性文件。
代码清单7：怎样调用ConfigManager 类以读取属性文件
