Object composition / Beziehungen zwischen Objekten

S

someDay

Aktives Mitglied
Thread Starter
Dabei seit
20.05.2006
Beiträge
490
Reaktionspunkte
5
Hallo,

Ich suche eine Moeglichkeit, sinnvoll Beziehungen zwischen Objekten zu definieren. Konkret habe ich ein Netz mit Knotenpunkten, einige dieser Knotenpunkte sind verbunden; Ein & Ausgaenge von Knotenpunkten werden seperat behandelt.

Gesucht ist eine sinnvolle Organisation des Modells, DH es muss folgende Fragen effizient beantworten koennen:

- Zu welchen Knotenpunkten fuehren die Ausgaenge eines Knotenpunkts X?
- Welche Knotenpunkte sind die Eingaenge eines Knotenpunkts Y?
- Wie identifiziere ich einen Knotenpunkt sinnvoll?

Nach dem Durchlesen meines Buches ("Learning Cocoa with Obj C", leider nicht sehr tiefgehend), Google und diversen Apple Seiten fand ich divereste Moeglichkeiten:
- a) Mittels Referenzen direkt in C. Nicht sehr schoen, und ich weiss im Moment noch nicht wie das in Zusammenhang mit NSArray & Co funktioniert.
b) Mittels eines selbstgestrickten Systems (ids der Knotenpunkte, Listen der jeweiligen Eingaenge, Listen der Ausgaenge, und noch paar Listen um das ganze sinnvoll zu verwalten). Nicht schoen.
c) Core Data - das klingt ja sehr schoen, scheint mir allerdings eher fuer den Fall von Daten aus Datenbanken & der Vereinfachung von grafische Applikationen konzipiert zu sein.
d) outlets - wobei diese auf NIB Files beschraenkt sind?

Weitere Fragen:
- Wenn ich von einem Object seine Speicheradresse und Typ weiss, wie kann ich dann eine Anweisung im Sinne von [ObjectAnSpeicheradresse machdas: mitdem und: dem] schicken?
- Bestellt habe ich mir die Objective C Pocket Referenz. Welche weiteren Buecher sind zu empfehlen?
(Vorwissen: Mehrere Jahre als WebDev gearbeitet, dh PERL, PHP werden sicher beherrscht, C beherrsche ich bis auf einige Dinge im Speichermanagment recht gut.)

sD.
 
someDay schrieb:
Hallo,

Ich suche eine Moeglichkeit, sinnvoll Beziehungen zwischen Objekten zu definieren. Konkret habe ich ein Netz mit Knotenpunkten, einige dieser Knotenpunkte sind verbunden; Ein & Ausgaenge von Knotenpunkten werden seperat behandelt.

Gesucht ist eine sinnvolle Organisation des Modells, DH es muss folgende Fragen effizient beantworten koennen:

- Zu welchen Knotenpunkten fuehren die Ausgaenge eines Knotenpunkts X?
- Welche Knotenpunkte sind die Eingaenge eines Knotenpunkts Y?
- Wie identifiziere ich einen Knotenpunkt sinnvoll?

"Effizienz" hat ja mir der Programmiersprache eher selten etwas zu tun, sondern mit dem Algorithmus.

Und dann ist die Frage: Was ist effizient? Die Komplexitätstheoretiker sind ja schon zufrieden, wenn ein Problem in Polynomialzeit lösbar ist -- und ich hab noch nicht genug Tee getrunken um das sagen zu können, aber ich glaub das geht hier.

Im übrigen hab ich das Problem noch nicht 100% verstanden. Wie sehen "Eingang", "Ausgang", und "Knoten" aus (d.h. welche Verbindungen haben sie?)

Meinst Du das "Learning Cocoa" Buch von O'Reilly? Oh je, das ist nun wirklich nicht zu empfehlen. Der Standard ist "Hillegass -- Cocoa Programming for OS X".

Und das mit "Objekt an Speicherstellte...": Wenn Du [meinObject machDas] tust, dann ist das NICHTS anderes.

Man kann das auch alles wunderbar in Objective C machen, aber auch in C++ oder so.

CoreData halte ich da nicht unbedingt für die beste Idee... aber theoretisch geht das auch.

Alex
 
someDay schrieb:
Gesucht ist eine sinnvolle Organisation des Modells, DH es muss folgende Fragen effizient beantworten koennen:

- Zu welchen Knotenpunkten fuehren die Ausgaenge eines Knotenpunkts X?
- Welche Knotenpunkte sind die Eingaenge eines Knotenpunkts Y?
- Wie identifiziere ich einen Knotenpunkt sinnvoll?
Wenn ich das richtig verstehe, dann möchtest Du Deine Daten mittels NSObject bzw. davon abgeleiteten (eigenen) Klassen im Arbeitsspeicher verwalten. Also ggf. auch aus einer Datei einlesen oder abspeichern.

Dann ist der erste Schritt eine "Knotenklasse" zu definieren. Die könnte in etwa so aussehen:
Code:
@interface MeinKnoten : NSObject
{
NSMutableArray *_eingänge;
NSMutableArray *_ausgänge;
NSString *_name;
}

- (NSArray *) eingangsknoten;
- (NSArray *) ausgangsknoten;
- (void) verbindeAusgangMit:(MeinKnoten *) knoten;
- (void) verbindeEingangMit:(MeinKnoten *) knoten;
- (NSString *) name;
- (void) setName:(NSString *) name;

@end
Identifiziert wird der Knoten über die Speicheradresse der Instanz, also MeinKnoten *knoten;

Aber beachte: dieses Konzept hat ein paar Fallstricke:
* verbindeAusgangMit: sollte idealerweise auch gleich die Rückwärtsverbindung machen - das kann wenn man nicht aufpaßt zu endlos-rekursion führen
* Einträge in einem NSMutableArray machen einen "retain". Und wenn ein Ausgangsknoten auch den Eingang wieder rückwärts gesetzt hat, dann wird das Objekt nie aus dem Speicher entfernt

-- hns
 
Danke euch beiden!

Gestern nacht wurde mit (im macdev channel) zuerst einmal ein ziemlicher Fehler in meinem Verstaendnis von Cocoa bewusst - bisher dachte ich, Eintraege in NSArray oder NSMutableArray seien Kopien und nicht Referenzen. (Was natuerlich falsch ist.)

@bounced: Sorry, ich beschrieb das nicht sehr genau. Das ganze ist ein typisches (neuronales) Netz, mit Knoten und Verbindungen zwischen den Knoten. Knoten haben Eingaenge und Ausgaenge, wobei Ausgaenge von Knoten mit Eingaengen von anderen Knoten verbunden sind. Bei zwei Knoten A & B, wobei A zu B fuehrt und B zu B und A, saehe das also so aus: Knoten sind {A,B}, Eingaenge(A) = {B}, Eingaenge(B) = {B,A}.

Eines der Probleme ist, das nicht von vornerein feststeht, wieviele Knoten es gibt und wie diese verteilt sind. Das heisst, das Programm muss wissen, das alle dieses Bs der ein und der gleiche Knoten sind. Hier dachte ich schlicht daran, als Bezeichnung fuer die Knoten schlicht ihr Platz im Speicher (also die <0x7373bde> etc Adressen) zu verwenden. Wie wuerde man so etwas normalerweise in ObjC loesen?

@hns: Vielen Dank fuer den Code!
Um eventuelle Probleme mit Rekursivitaet zu verhindern und um Berechnungen des ganzen Netzwerks zu vereinfachen enthaelt meine aktuelle Knotenklasse nicht die Informationen ueber Eingaenge/Ausgaenge anderer Knoten, sondern lediglich eine Moeglichkeit die Werte an diesen Eingaengen zu setzen und die Ausgabe eines Knotens zu berechnen.
Diese Knoten zu einem Netzwerk (und damit die Informationen zu Ein & Ausgaengen) wollte ich in einer seperaten "Netz" Klasse durchfuehren.
Die Artikel zum Speichermanagment (retain/release.. hm.) werde ich mir besser nochmal durchlesen, ich glaube das habe ich noch nicht ganz verstanden.

Nochmals Danke!

sD.
 
someDay schrieb:
Hier dachte ich schlicht daran, als Bezeichnung fuer die Knoten schlicht ihr Platz im Speicher (also die <0x7373bde> etc Adressen) zu verwenden. Wie wuerde man so etwas normalerweise in ObjC loesen?

Ich schlage Dir doch mal vor, Dir die Grundlagen der objektorientierten Programmierung anzusehen.

Der Zeiger auf ein Objekt ist immer "der Platz im Speicher" (der aktuellen virtuellen Speichertabelle), also aus der Sicht des Betriebssystems siehst Du das ganz richtig.

Allerdings glaube ich, dass Dir ein Verständnis von OO Konzepten und Paradigmen helfen kann, Dein Problem einfacher zu lösen.

Alex
 
Hallo,

Danke fuer den Hinweis, ich weiss wie man OOP programmiert.

Mir geht es jedoch konkret um die Umsetzung in ObjC und Cocoa. Wie erwaehnt, ich habe mit diesen Tools bisher nicht gearbeitet, meine ersten Erfahrungen mit Cocoa sehen jedoch so aus das fuer die meisten Probleme es eine effiziente Loesung vorsieht. (Nein, effizient nicht im komplexitaetstheoretischen Sinn.) Daher nehme ich an, das dieses (sicherlich gelegentlich auftretende) Problem von Relationen zwischen Objekten bestimmt schon zahllose Male geloest wurde und ich das Rad nicht neu erfinden moechte.

sD.
 
Richtig!

Und wenn Du einmal den Kopf freimachst, und nicht "Objective-C" sondern "einfache eine andere OO Sprache" denkst wirst Du sehen, dass Du wahrscheinlich alles schon begriffen hast.

Es werden fast überall nur Referenzen gespeichert, und die kannst Du dann in Deinem Fall mit if (ObjectA = ObjectB) prüfen.

Wenn Du fortgeschritten bist, empfehle ich Dir die "Gang Of Four"

Alex
 
Zurück
Oben Unten