[myObject release]

Das Wichtigste zuerst: Man sendet nie selbst ein dealloc.

Du meinst mutmaßlich, dass die Person insgesamt aus dem Programm verschwinden soll. Das ist jetzt kein Problem der Speicherverwaltung und lässt sich daher auch nicht mit Mitteln der Speicherverwaltung lösen. In diesem Falle muss man tatsächlich alle Gruppen durchmarschieren und die Person entfernen. Das geschieht dann eben in einem Controller, der von allem – inklusive der Weihnachtsfeier – weiß.

Eine andere Möglichkeit ist es, eine Notification auszulösen, damit alle anderen Programmteile entsprechend die Person löschen können.

Original von Amin Negm-Awad
Das Wichtigste zuerst: Man sendet nie selbst ein dealloc.

Einzige Ausnahme: in der Implementierung einer dealloc-Methode schickt man natürlich ein dealloc an super.

Michael

Original von D.Mon
Etwas einfacher wird es nach der Einführung von -setGroup in der Person Klasse. Dadurch weiß die Person, dass sie Leiter einer Gruppe ist und kann sich im Todesfall aus dieser Gruppe selbst wieder abmelden.

Das klingt herrlich schräg.

Mal ernsthaft, es ist doch ein wenig skurril, wenn die letzten Worte des Herrn Mayer sind: "Verdammt, ich bin doch Leiter der Gruppe Einkauf!" zum Telefon greift und sofort seinen Rausschmiss verlangt, da er in wenigen Sekunden sterben wird.

Im Modell hat das (aka. die Logik) nix verloren. Dass der Mayer die Eigenschaft 'Gruppenleiter' besitzt ist okay, dass diese geändert werden kann auch. Aber Herr Mayer muss sich doch nun wirklich keinen Kopf darum machen ob er noch immer der Abteilung angehört, was nach einer Beförderung passiert und wie es nach einer Kündigung ausschaut.

Original von D.Mon
Was ich nicht ganz verstanden habe, was Du mit "alle Gruppen durchmaschieren" meinst.
nach meinem bisherigen Kenntnisstand würde das nur gehen, wenn man die Gruppen in einer Collection speichert. Ist es das, was mit "Controlller" gemeint ist? Oder gibt es eine andere Möglichkeit, innerhalb des Programms herauszufinden, welche Gruppen(objekte) es zu einem bestimmten Zeitpunkt gibt? Vermutlich nicht.

Im Speichermanagement hast du gelernt:
- nutze Accessoren!

Du baust eine Firma auf, also brauchst du eine Collection an Mitarbeitern. Und an Abteilungen. Und an Dienstwagen, Gehaltsstufen, Jubiläen und weißdergeier.

Um das alles im Griff zu haben brauchst du einen Controller, der eben diese ganzen Dinge verwaltet. Für die Personen ist zum Beispiel ein ArrayController der einzige Controller. Für die Abteilungen ein Anderer. Willst du die beiden synchron halten, brauchst du einen weiteren Controller, der sagt, was die anderen tun sollen.

Du sagst jeder Collection Dinge wie 'MitarbeiterCollection, nimm den Mayer auf' und die MitarbeiterCollection nimmt den Mayer auf.
[personController addObject:egonMayer];

Du sagst speziell 'GruppenCollection, sag der Gruppe Einkauf, der Mayer ist ihr Boss' und schon ist der Mayer Boss des Einkaufs.
[[groupController objectWithName:@"Einkauf"] setLeader:egonMayer];

Das waren ein paar Accessoren. Solange der Mayer noch irgendwo gespeichert ist, kann er nicht tot sein. Dementsprechend musst du ihn auch per Accessoren wieder rauswerfen.

Nun ist der Mayer aber befördert worden.
Du sagst 'GruppenCollection, sag der Gruppe Einkauf, der Mayer hat nix mehr zu sagen' und schon ist der Einkauf ungeleitet. Willst du vertretungsweise den Schulze einspringen lassen, sagst du 'GruppenCollection, sag der Gruppe Einkauf, der Schulze hat jetzt das Sagen.' und so sei es.
Nun musst du dem Mayer noch mitteilen, dass er ein neues Aufgabengebiet hat. Sonst bekommt der sich am nächsten Arbeitstag mit dem Schulze in die Haare und es gibt ein Kompetenzgerangel.
'MitarbeiterCollection, sag dem Mayer, dass er jetzt die IT leitet.' Und dann fällt dir noch ein: 'FinanzCollection, setz den Lohn vom Mayer auf Tarifstufe 7 hoch und buch nen Firmenwagen dazu.'

Eine Collection verwaltet viele gleiche Objekte (muss sie nicht, tut sie aber in 98,11% aller Fälle).
Eine Collection verwaltet nicht unzählige unterschiedliche Objekte (zumindest nicht in 98,11% aller Fälle).

Daher kann deine Collection nicht alles allein machen, du brauchst einen weiteren Controller.
So wie sich ein Mitarbeiter nicht alles selbst merken muss, dafür gibt es ja die Personalabteilung.

Nu stirbt der Mayer... Och nee, wie negativ!
Nun geht der Mayer in Vorruhestand.

Jetzt muss dein Controller folgendes tun:
- allen Abteilungen (GruppenCollection) mitteilen: 'Jede Gruppe, die den Mayer als Vorgesetzten hat, nimmt ihn bitte raus.'
- der Finanzabteilung (FinanzCollection) sagen: 'Der Mayer bekommt nix mehr von uns, der Dienstwagen ist auch gestrichen. Ach, nehmt ihn am Besten ganz raus.'
- der Personalverwaltung (PersonenCollection) anweisen: 'Der Mayer arbeitet hier nicht mehr.'
- dem Fuhrpark (KFZCollection) erklären: 'Der Mayer ist nicht länger Fahrer des Fahrzeuges AA-BB 1234.'

Und so weiter...

Das kann auf zweierlei Arten passieren.
Entweder schickt der Mayer nen Brief an die Personalabteilung, die das Ganze durchführt.
Oder die Personalabteilung lässt es sich nicht nehmen, sich jede gravierende Änderung des Personalwesens schon im Vorfelde mitteilen zu lassen.

Erstens wäre die direkte Mitteilung per -personIstImRuhestand:egonMayer
Zweitens wäre eine Notification wie "person:egonMayer WirdInDenRuhestandGehenAm:heutigenTage".









PS:
Sollte ein gewisser Herr Egon Mayer mitlesen, der zufällig Abteilungsleiter Einkauf eines Unternehmens war, zum Abteilungsleiter IT gewechselt hat und nun seinen wohl verdienten Vorruhestand genießt: sämtliche Erlöse dieses Beitrages gehen natürlich zu 98,11% an Sie. Mailden Sie sich einfach.

Original von D.Mon
Im Endeffekt läuft es wohl darauf hinaus, dass jede mögliche Veränderung im Voraus mit allen möglichen Auswirkungen bedacht werden muss und dementsprechende Methoden erstellt werden müssen. Das Ganze auch noch effizient, logisch und gut strukturiert hinzubekommen bedarf wohl einer gewissen Übung und Erfahrung.

Exakt. =)
Das macht aber auch den meisten Spaß aus.
Und irgendwas übersieht man oder hat man falsch geplant, so dass ein Update fällig wird.

Original von D.Mon
Vielen Dank, das war sehr ausführlich — muss ich erstmal verdauen.

Im Endeffekt läuft es wohl darauf hinaus, dass jede mögliche Veränderung im Voraus mit allen möglichen Auswirkungen bedacht werden muss und dementsprechende Methoden erstellt werden müssen. Das Ganze auch noch effizient, logisch und gut strukturiert hinzubekommen bedarf wohl einer gewissen Übung und Erfahrung.

Jedenfalls hab ich hier schon wieder eine Menge Denkanstösse bekommen. Danke.

Gruß
D.Mon

Jein, alle möglichen Varianten kannst du nicht durchdenken. Es sind unermesslich viele. Und in der Tat ist das ein häufiger Fehler in Programmen. Kennt man ja: "Wenn man X so einstellt und Y so und dann die Funktion Z ausführt, stürzt das Programm ab" oder so ähnlich.

Damit stehst du aber nicht alleine, da es eben der übliche Fehler ist. Und deshalb machen sich schlaue Leute darüber Gedanken, wie man das vermeidet. Es gibt verschiedene Methoden, das in den Griff zu bekommen, denen eine zugrunde liegt: Kapselung!

Du wirst noch vieles kennenlernen zur Strukturierung, die verschiedenen Controller-Typen, Notifications zur Asynchronen Programmstrukturierung usw. usf. Es ist eigentlich sehr schön, dass du das Problem so früh erkannt hast. Dir wird manches schneller klar sein.

Merke Dir jetzt schon: Kleine Einheiten, die klare Aufgaben bekommen und aufgrund definierter Nachrichten agieren, vermindern diese Problematik.