Objekt instantieren und sofort in Container speichern
-
Hallo zusammen!
Der Titel sagt eigentlich schon fast alles.. ich will, dass ein Objekt einer Klasse nicht erzeugt werden kann, ohne dass es in einem Container steht.Ich such jetzt schon ewig und komme nicht dahinter -.-
bitte um hilfe
mfg simon
-
simon90 schrieb:
Hallo zusammen!
Der Titel sagt eigentlich schon fast alles.. ich will, dass ein Objekt einer Klasse nicht erzeugt werden kann, ohne dass es in einem Container steht.Um WAS zu tun? Das ist ne etwas seltsame Anforderung, du versuchst da bestimmt irgendwas zu erreichen was auch anders umsetzbar ist.
-
Da müsstest du schon deinen eigenen Container für schreiben, der dann Exklusivrechte auf die Erzeugung dieser Objekte bekommt.
Gegenfrage: Wozu soll das gut sein?
-
Das geht natürlich in dem du einfach eine statische Funktion in der Klasse erstellst, die als Parameter den Container bekommt und dafür dann das Objekt anlegt. Den Konstruktor einfach dann nicht public machen. "Müsste" gehen (ungetestet). Finde ich aber auch häßlich. Hat mich bei meiner Frau aber auch nicht abgehalten.
-
vllt habt ihr recht und es geht viel einfacher.. vllt sitz ich schon den ganzen tag und verstricke mich immer weiter rein und verlier den Überblick
Ich arbeite mit DirectX und möchte ca 30 Objekte erzeugen welche später gezeichnet werden. Damit ich 1) keins vergesse und 2) mich nicht darum kümmern muss, möchte ich sie in eine liste
-
Dann erzeug sie und pack sie dann in eine Liste...
-
Fellhuhn schrieb:
Das geht natürlich in dem du einfach eine statische Funktion in der Klasse erstellst, die als Parameter den Container bekommt und dafür dann das Objekt anlegt. Den Konstruktor einfach dann nicht public machen. "Müsste" gehen (ungetestet). Finde ich aber auch häßlich. Hat mich bei meiner Frau aber auch nicht abgehalten.
klingt ganz gut und werd ich mal so probieren danke mal für die schnellen antworten
-
Ich such jetzt schon ewig und komme nicht dahinter -.-
Im Konstruktor kann das Objekt sich selbst im "Objektmanager" eintragen. Beim Defaultkonstruktor kann ja ein default Objektmanager stehen (wahrscheinlich als Singleton realisert). Oder aber du bietest eine ueberladene Variante des Konstruktors an, in dem du den Container als Parameter angibst.
Um WAS zu tun? Das ist ne etwas seltsame Anforderung, du versuchst da bestimmt irgendwas zu erreichen was auch anders umsetzbar ist. ... Gegenfrage: Wozu soll das gut sein?
Nein, das ist keine seltsame Anforderung. Angenommen du schreibst ein (Baller)Spiel und feuerst Projektile ab. Dann sollen bei der Erzeugung der Projektile durch die Feuerwaffe, diese der Welt automatisch als physikalische Objekte hinzugefuegt werden, ohne dass fuer die Kanone (-kugel, Projektil) die Welt als expliziter Parameter bekannt ist.
-
Kommt zwar drauf an, aber wahrscheinlich wäre es bei dir sinnvoll, wenn sich deine Objektinstanzen selbst aus einer statischen Liste ein- und austragen (d.h. im Konstruktor/Destruktor).
-
Fellhuhn schrieb:
Das geht natürlich in dem du einfach eine statische Funktion in der Klasse erstellst, die als Parameter den Container bekommt und dafür dann das Objekt anlegt. Den Konstruktor einfach dann nicht public machen. "Müsste" gehen (ungetestet). Finde ich aber auch häßlich. Hat mich bei meiner Frau aber auch nicht abgehalten.
Alternative dazu, bzw. ähnliches Prinzip: Eine Factory die die exklusiven Erzeugungsrechte hat und die Objekte in einem entsprechenden Container unterbringt.
-
knivil schrieb:
Um WAS zu tun? Das ist ne etwas seltsame Anforderung, du versuchst da bestimmt irgendwas zu erreichen was auch anders umsetzbar ist. ... Gegenfrage: Wozu soll das gut sein?
Nein, das ist keine seltsame Anforderung. Angenommen du schreibst ein (Baller)Spiel und feuerst Projektile ab. Dann sollen bei der Erzeugung der Projektile durch die Feuerwaffe, diese der Welt automatisch als physikalische Objekte hinzugefuegt werden, ohne dass fuer die Kanone (-kugel, Projektil) die Welt als expliziter Parameter bekannt ist.
Klar macht es Sinn, den "Erzeugen" und den "Merken" Teil irgendwie an einer Stelle zusammenzufassen, so dass man es nicht zigfach wiederholen muss.
Das heisst aber nicht, dass man es unbedingt unmöglich machen muss, die beiden Teile getrennt auszuführen. Im Gegenteil, man erzwingt dadurch eine enge Kopplung von zwei Klassen, die oft nicht nötig wäre.
p.S.: natürlich muss man die Klassen nicht direkt koppeln. Man muss aber zumindest die zu Erzeugende Klasse eng an die Factory binden (auch wenn die Factory ein unabhängiger Teil ist), und die Factory wiederum benötigt eine (möglicherweise recht lose) Kopplung mit der Container Klasse. Insgesamt alles also wesentlich restriktiver als IMO nötig.
