Все одноэлементные шаблоны Java (как этот, так и стандартный с закрытым конструктором и статическим средством доступа) имеют это плохое свойство, что если вы их тестируете (или тестируете все, что даже удаленно зависит от них), можете использовать этот и только этот объект.
Например, если вы хотите проверить класс PrintingService
, который зависит от PrintingSingleton
, вы не сможете заменить этот печатный синглтон на макет, потому что он статически связан.
т.е. представьте себе тестирование этой функции
boolean printDocument(Document d) {
if (PrintingSingleton.INSTANCE.isPrinterEnabled()) {
PrintingSingleton.INSTANCE.print(d);
}
throw new RuntimeExeption("Printing not enabled");
}
с тестом
@Test(expectedExceptions = {RuntimeException.class})
public void testPrinting() {
PrintingService service = ...
service.print(new Document()); // How will you simulate
// throwing an exception?
}
Лично я бы просто не использовал синглтоны таким образом, а скорее ввел бы внедрение зависимостей через Guice, Spring или Pico Container. Таким образом, вы гарантируете существование только одного объекта, не ограничивая себя тем, что не можете смоделировать объект, например, для испытаний.