From 9a2c5aa9aaf355b8e22cfc0b7392283d153f780a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ilkka=20Sepp=C3=A4l=C3=A4?= Date: Tue, 22 Jun 2021 20:10:26 +0300 Subject: [PATCH] Update singleton --- singleton/README.md | 27 ++++++++++++------- .../main/java/com/iluwatar/singleton/App.java | 16 +++++------ 2 files changed, 25 insertions(+), 18 deletions(-) diff --git a/singleton/README.md b/singleton/README.md index 5f058ffea..ffff61e15 100644 --- a/singleton/README.md +++ b/singleton/README.md @@ -13,13 +13,12 @@ tags: Ensure a class only has one instance, and provide a global point of access to it. - ## Explanation -Real world example +Real-world example > There can only be one ivory tower where the wizards study their magic. The same enchanted ivory -> tower is always used by the wizards. Ivory tower here is singleton. +> tower is always used by the wizards. The ivory tower here is a singleton. In plain words @@ -46,9 +45,17 @@ public enum EnumIvoryTower { Then in order to use: ```java -var enumIvoryTower1 = EnumIvoryTower.INSTANCE; -var enumIvoryTower2 = EnumIvoryTower.INSTANCE; -assertEquals(enumIvoryTower1, enumIvoryTower2); // true + var enumIvoryTower1 = EnumIvoryTower.INSTANCE; + var enumIvoryTower2 = EnumIvoryTower.INSTANCE; + LOGGER.info("enumIvoryTower1={}", enumIvoryTower1); + LOGGER.info("enumIvoryTower2={}", enumIvoryTower2); +``` + +The console output + +``` +enumIvoryTower1=com.iluwatar.singleton.EnumIvoryTower@1221555852 +enumIvoryTower2=com.iluwatar.singleton.EnumIvoryTower@1221555852 ``` ## Class diagram @@ -62,13 +69,13 @@ Use the Singleton pattern when * There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point * When the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code -## Typical Use Case +Some typical use cases for the Singleton * The logging class * Managing a connection to a database * File manager -## Real world examples +## Known uses * [java.lang.Runtime#getRuntime()](http://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#getRuntime%28%29) * [java.awt.Desktop#getDesktop()](http://docs.oracle.com/javase/8/docs/api/java/awt/Desktop.html#getDesktop--) @@ -77,8 +84,8 @@ Use the Singleton pattern when ## Consequences -* Violates Single Responsibility Principle (SRP) by controlling their own creation and lifecycle. -* Encourages using a global shared instance which prevents an object and resources used by this object from being deallocated. +* Violates Single Responsibility Principle (SRP) by controlling their creation and lifecycle. +* Encourages using a globally shared instance which prevents an object and resources used by this object from being deallocated. * Creates tightly coupled code. The clients of the Singleton become difficult to test. * Makes it almost impossible to subclass a Singleton. diff --git a/singleton/src/main/java/com/iluwatar/singleton/App.java b/singleton/src/main/java/com/iluwatar/singleton/App.java index 4c02262d2..b5eed98da 100644 --- a/singleton/src/main/java/com/iluwatar/singleton/App.java +++ b/singleton/src/main/java/com/iluwatar/singleton/App.java @@ -30,20 +30,20 @@ import lombok.extern.slf4j.Slf4j; * classloader instance and provides global access to it.

* *

One of the risks of this pattern is that bugs resulting from setting a singleton up in a - * distributed environment can be tricky to debug, since it will work fine if you debug with a + * distributed environment can be tricky to debug since it will work fine if you debug with a * single classloader. Additionally, these problems can crop up a while after the implementation of - * a singleton, since they may start out synchronous and only become async with time, so it may - * not be clear why you are seeing certain changes in behaviour.

+ * a singleton, since they may start synchronous and only become async with time, so it may + * not be clear why you are seeing certain changes in behavior.

* *

There are many ways to implement the Singleton. The first one is the eagerly initialized * instance in {@link IvoryTower}. Eager initialization implies that the implementation is thread - * safe. If you can afford giving up control of the instantiation moment, then this implementation + * safe. If you can afford to give up control of the instantiation moment, then this implementation * will suit you fine.

* - *

The other option to implement eagerly initialized Singleton is enum based Singleton. The - * example is found in {@link EnumIvoryTower}. At first glance the code looks short and simple. + *

The other option to implement eagerly initialized Singleton is enum-based Singleton. The + * example is found in {@link EnumIvoryTower}. At first glance, the code looks short and simple. * However, you should be aware of the downsides including committing to implementation strategy, - * extending the enum class, serializability and restrictions to coding. These are extensively + * extending the enum class, serializability, and restrictions to coding. These are extensively * discussed in Stack Overflow: http://programmers.stackexchange.com/questions/179386/what-are-the-downsides-of-implementing * -a-singleton-with-javas-enum

* @@ -56,7 +56,7 @@ import lombok.extern.slf4j.Slf4j; * ThreadSafeLazyLoadedIvoryTower} since it doesn't synchronize the whole access method but only the * method internals on specific conditions.

* - *

Yet another way to implement thread safe lazily initialized Singleton can be found in + *

Yet another way to implement thread-safe lazily initialized Singleton can be found in * {@link InitializingOnDemandHolderIdiom}. However, this implementation requires at least Java 8 * API level to work.

*/