The document discusses the Singleton pattern in Java. It describes how a singleton ensures that only one instance of a class exists. It provides examples of implementing a lazy singleton using a static holder class to defer initialization until needed. The document also discusses how depending on static getInstance() calls can make code difficult to test. It proposes using a Supplier interface instead to allow injecting mock dependencies for testing.

1. The Singleton
Pattern in Java
1

2. What is the Singleton Pattern?
• A commonly used idiom to create and maintain objects called
singletons
• A singleton is the only instance of a class
• Common use cases:
• A user’s preferences in a desktop application
• Cache
• Resource pool
2

3. Example: interface for fetching weather from
an external web service
interface WeatherFetcher {
String fetchWeather(String cityCode) throws IOException;
int fetchTemperature(String cityCode) throws IOException;
}
• Imagine that we are working on a feature which uses this interface
• We need to maintain a connection pool in order to reduce latency
• We want to make sure that we will have only one connection pool, which is
a good use case for the Singleton pattern
3

4. Singleton which maintains the connection pool
public class SimpleSingleton implements WeatherFetcher {
private static final SimpleSingleton INSTANCE = new SimpleSingleton();
public static WeatherFetcher getInstance() { return INSTANCE; }
private SimpleSingleton() { System.out.println("Populating the connection pool..."); }
@Override public int fetchTemperature(String cityCode) {
// gets an idle connection from the pool, sends a request
return 71; // please assume it's from a response
}
@Override public String fetchWeather(String cityCode) {
// gets an idle connection from the pool, sends a request
return "Sunny"; // please assume it's from a response
}
// client code
public static void main(String[] args) throws IOException {
WeatherFetcher singleton = SimpleSingleton.getInstance();
System.out.printf("Weather in New York: %s, %dFn",
singleton.fetchWeather("NewYork"), singleton.fetchTemperature("NewYork"));
}
} 4

5. Another requirement: defer initialization until
it’s really necessary
public static void main(String[] args) throws IOException {
System.out.println("Doing some other stuff - I don't need the connection pool yet"); // added
WeatherFetcher singleton = SimpleSingleton.getInstance();
System.out.printf("Weather in New York: %s, %dFn",
singleton.fetchWeather("NewYork"), singleton.fetchTemperature("NewYork"));
}
// The main method yields the following output:
Populating the connection pool...
Doing some other stuff - I don't need the connection pool yet
Weather in New York: Sunny, 71F
• SimpleSingleton’s constructor gets called before the getInstance() call
• Unnecessary resource consumption (initializing the connection pool)
might be imposed on the user 5

6. Lazy singleton with a static holder class
public class LazySingleton implements WeatherFetcher {
private static class SingletonHolder {
static final LazySingleton INSTANCE = new LazySingleton();
}
public static WeatherFetcher getInstance() { return SingletonHolder.INSTANCE; }
private LazySingleton() { System.out.println("Populating the connection pool..."); }
...
// client code
public static void main(String[] args) throws IOException {
System.out.println("Doing some other stuff - I don't need the connection pool yet");
WeatherFetcher singleton = LazySingleton.getInstance();
System.out.printf("Weather in New York: %s, %dFn",
singleton.fetchWeather("NewYork"), singleton.fetchTemperature("NewYork"));
}
}
// Now the main method yields:
Doing some other stuff - I don't need the connection pool yet
Populating the connection pool...
Weather in New York: Sunny, 71F 6

7. New requirement: generating a weather report
public class WeatherReporter {
String generateWeatherReport(List<String> cityCodeList) {
StringBuilder sb = new StringBuilder("=== Weather Report ===n");
for (String cityCode : cityCodeList) {
try {
String weather = LazySingleton.getInstance().fetchWeather(cityCode);
int temperature = LazySingleton.getInstance().fetchTemperature(cityCode);
sb.append(String.format("%s: %s, %dFn", cityCode, weather, temperature));
} catch (IOException e) {
sb.append(String.format("%s: Failed to fetch datan", cityCode));
}
}
return sb.toString();
}
}
• Writing unit tests is almost impossible due to static getInstance() calls
• Setting up a data source for testing is too much effort
• Problem: business logic tightly coupled to an external data source
7

8. Workaround: replacing getInstance() by Supplier
public class ImprovedWeatherReporter {
private final Supplier<? extends WeatherFetcher> weatherFetcherSupplier;
public ImprovedWeatherReporter(Supplier<? extends WeatherFetcher> weatherFetcherSupplier) {
this.weatherFetcherSupplier = weatherFetcherSupplier;
}
String generateWeatherReport(List<String> cityCodeList) {
StringBuilder sb = new StringBuilder("=== Weather Report ===n");
for (String cityCode : cityCodeList) {
try {
String weather = weatherFetcherSupplier.get().fetchWeather(cityCode);
int temperature = weatherFetcherSupplier.get().fetchTemperature(cityCode);
sb.append(String.format("%s: %s, %dFn", cityCode, weather, temperature));
} catch (IOException e) {
sb.append(String.format("%s: Failed to fetch datan", cityCode));
}
}
return sb.toString();
}
}
8

9. Unit tests for ImprovedWeatherReporter
@ExtendWith(MockitoExtension.class) class ImprovedWeatherReporterTest {
@Mock WeatherFetcher weatherFetcher;
ImprovedWeatherReporter sut;
@BeforeEach void setUp() { sut = new ImprovedWeatherReporter(() -> weatherFetcher); }
@Test void producesReports() throws IOException {
when(weatherFetcher.fetchTemperature("NewYork")).thenReturn(71);
when(weatherFetcher.fetchWeather("NewYork")).thenReturn("Sunny");
when(weatherFetcher.fetchTemperature("Montreal")).thenReturn(68);
when(weatherFetcher.fetchWeather("Montreal")).thenReturn("Cloudy");
String actual = sut.generateWeatherReport(Arrays.asList("NewYork", "Montreal"));
assertThat(actual).isEqualTo("=== Weather Report ===n" +
"NewYork: Sunny, 71Fn" +
"Montreal: Cloudy, 68Fn");
}
@Test void exception() throws IOException {
when(weatherFetcher.fetchTemperature("Tokyo")).thenThrow(new IOException("catch this"));
String actual = sut.generateWeatherReport(Collections.singletonList("Tokyo"));
assertThat(actual).isEqualTo("=== Weather Report ===n" +
"Tokyo: Failed to fetch datan");
}
}
9

10. Conclusion
• We’ve discussed:
• A couple of common idioms of the Singleton Pattern in Java
• A maintainability issue that can be caused by applying the pattern
• Having getInstance() calls in the middle of business logic can make
code unit test unfriendly
• Introducing a Supplier field instead of getInstance() calls can be a
quick workaround for making code unit test friendly
10