Suggest an editImprove this articleRefine the answer for “When is Singleton actually justified?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**Singleton** is justified only when having a **single instance is logically necessary** and does not break the modularity of the system, for example for global system resources or infrastructure services. **Key point:** Singleton is justified when the uniqueness of the object is inherent to the nature of the task and alternative solutions (DI, factories, contexts) would be excessive.Shown above the full answer for quick recall.Answer (EN)Image**Singleton** is justified only when having a **single instance is logically necessary** and does not break the modularity of the system. ### Global system resources For example, a logger, a configuration manager, a database connection driver, a thread pool. Here there really should be **one object** managing shared state. ### Hardware or external interfaces When interacting with external devices (printer, port, sensor), it is important to have a single access point to avoid conflicts on simultaneous access. ### Infrastructure services Caching systems, routing, event buses, task schedulers - anything that keeps the rest of the logic running and does not depend on business context. ### When the lifecycle is easy to control If the application is small and Singleton does not create testing problems (for example, in desktop or embedded scenarios), using it simplifies the structure. **Conclusion:** Singleton is justified when **the uniqueness of the object is inherent to the nature of the task** and when **alternative solutions (DI, factories, contexts)** would be excessive. In other cases it is better to avoid it, so as not to create hidden dependencies and tight coupling.For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.