<aside> 💡

Een Singleton zorgt dat er van een klasse maximaal één instantie bestaat, en geeft daar één centraal toegangspunt toe.

</aside>

Het probleem

Stel je hebt een AudioManager die de muziek en geluidseffecten van het spel afspeelt. Als iedere klasse die geluid nodig heeft zomaar zijn eigen new AudioManager() aanmaakt, krijg je al snel meerdere managers die elkaar overschrijven, dubbele achtergrondmuziek, en instellingen (volume, mute) die niet overal kloppen. Je wilt maar één AudioManager, en iedereen moet bij diezelfde instantie kunnen.

De oplossing

1. Een private static veld dat de ene instantie vasthoudt.
2. Een private constructor, zodat niemand van buitenaf zelf een nieuwe kan maken met new.
3. Een public static methode (of property) die de instantie teruggeeft — en 'm de eerste keer aanmaakt als hij nog niet bestaat.

UML-diagram

In het diagram zie je:

• Het stereotype «singleton» boven de klassenaam — geen officieel UML-symbool, maar een gangbare manier om het pattern te labelen.
• instance: AudioManager, onderstreept — onderstrepen betekent static in UML.
• AudioManager() — de constructor, met een minnetje: private.
• + Instance(): AudioManager, ook onderstreept — de static toegangsmethode.
• Een gestippelde pijl vanaf Speler — een Dependency: Speler roept AudioManager.Instance() aan, maar slaat er nergens een referentie van op als attribuut.

Code voorbeelden

• Klassiek voorbeeld c#
• Voorbeeld in de Unity engine

Wanneer gebruik je een Singleton?

• Er kan/mag er logisch gezien maar één van bestaan: een GameManager, een AudioManager, een SaveSystem.