Hallo Peter,

der Singleton ist das einzelne Objekt, nicht der Wert, der im Singleton-Objekt geführt wird.

Der Begriff Subklasse ist übrigens irreführend, dabei denkt man in der OOP eher an Vererbung. Das ist hier nicht der Fall. Mir fällt aber auf die Schnelle auch kein allgemeingültiger knackiger Begriff ein. Kindklasse?

Generell: kann man so machen, muss man aber nicht.

Wenn MyClass tatsächlich verantwortlich ist für die Erzeugung von SubClass-Instanzen, dann sind die beiden eng verzahnt und es wäre legitim, dass das MyClass-Objekt sich selbst an den Konstruktor von SubClass übergibt. Die Aufgabe, den Zähler zu führen (oder das zu mutierende Dings) könnte dann in MyClass liegen und einfach Teil des Eltern-Kind-Kommunikationsprotokolls sein.

class MyClass {
   #commonValue;
   #children;

   commonValue get() {
      return this.#commomValue;
   }
   commonValue set(newValue) {
      this.#commonValue = newValue;
      // Add common logic here
   }

   createChildren(n) {
      this.#children = new Array(n);  // push nur nehmen wenn nötig!
      for (let i=0; i<n; i++)
         this.#children[i] = new SubClass(this);
   }
}

class SubClass {
   #parent;
   constructor(parent) {
      this.#parent = parent;
   }

   doSomething() {
      this.#parent.commonValue = "drölf";
   }
}

Wie auch immer der BusinessCase genau dazu aussieht. Jedenfalls ist für eine so enge Koppelung ein separates Counter-Objekt nicht zwingend. Eine best practice kann man, ohne die konkrete Praxis zu kennen, schlecht benennen. Wie ich schon sagte: da ist vieles kontextabhängig.

Wenn Du Methoden hast, die im Prinzip nichts weiter tun als einen Wert setzen, kannst Du wie bei commonValue gezeigt auch Propertygetter und -setter verwenden.

Rolf