Singleton Modification Leads to Code Quality Issues: Analysis and Improvement Suggestions

The author describes a recent issue where a singleton object was inadvertently modified due to a change in a factory method.

Originally, the method

public static XXScene defaultInstance() { return new XXScene(); }

created a new instance each call.

After modification, it became

public static XXScene getDefaultInstance() { return defaultInstance; }

, returning a shared singleton, and added a check method

public boolean checkDefaultObj() { return this.equals(defaultInstance); }

.

This change altered semantics: callers expecting a fresh object now receive the same singleton, leading to unintended shared state.

Further encapsulation hid the singleton semantics, making the intent unclear in higher‑level code such as

public XXScene getXXScene(String tntInstId, ConfType confType, String evCode) { return getFirst(tntInstId, confType, evCode, XXScene::getDefaultInstance()); }

.

Because the method signature does not reveal the singleton nature, developers mistakenly treat the returned object as a new instance and modify it, causing the singleton to be altered.

The author identifies three core problems:

The singleton semantics of XXScene are not protected.

When the singleton semantics changed, the ConfigRepo interface was not updated accordingly.

Later developers implemented functionality via a “patch” approach, failing to integrate with the original code.

The root cause is described as “rough” internal quality: external behavior appears correct but internal code quality is poor, leading to strange bugs.

To improve internal quality, the author suggests:

Developers should continuously improve design skills and encapsulate mutable state, e.g., by adding layers that prevent writes to the singleton.

Teams need to foster an environment that produces high‑quality code, treating code as a clear expression of the problem, and invest time in refactoring; regular practices such as pair programming and daily code reviews are essential.

Management should shift performance metrics from punitive measures to positive incentives that reward activities like code reviews and pair programming, thereby encouraging genuine quality improvements rather than superficial fixes.

The conclusion lists three key points to avoid low‑level coding mistakes: give developers sufficient time and focus, institute daily code‑review activities, and align company incentives with genuine quality improvement rather than punitive metrics.