2012-03-25 3 views
1

Ich bekomme den Hang von iOS und arbeite mit den verschiedenen Frameworks. Mein Projekt wird (natürlich) immer komplexer und ich denke, ich mache einige Dinge auf verschlungene Weise.der Delegierte meines Delegierten ist ... (Entwurfsmuster)

Ich frage mich, ob es ein einfacheres Design-Muster ist mit dieser Situation zu umgehen:

App mit vielen in einer Reihe gehalten Eigenschaften; hält auch NSDictionary von NSDictionaries, die die Optionen für jede Eigenschaft darstellen.

Property Editor: präsentiert Tabelle für Detailansicht aktuellen Eigenschaften mit Bearbeitungsoption Anzeigen

Detailansicht: Tabelle zeigt mit allen Optionen für eine bestimmte Eigenschaft

ich jetzt diese Arbeit habe von:

App -> stellt sich als Delegierter Property Editor, die die del zugreift egate der (App) aktuellen Eigenschaften und die Arrays von Eigenschaftenoptionen

Property Editor -> stellt sich als Delegierter für jede Detailansicht und setzt Eigenschaft auf Detailansicht darstellt entsprechende Anordnung von Eigenschaftenoptionen von Delegierten

Detailansicht -> entsprechende Reihe von Immobilienoptionen

Dies scheint ziemlich verschlungen. Wäre es besser, die Detailansicht delegieren meine App? Gibt es ein Entwurfsmuster, das klarer ist? Ich erkenne, dass es eine enge Verbindung zwischen all diesen Klassen gibt, aber ich sehe nicht, wie das vermeidbar ist.

Antwort

1

Warum erstellen Sie nicht eine Singleton-Klasse für den Zugriff auf alle Ihre App-Eigenschaften (nennen wir es PropertiesContainer). Diese Klasse enthält die erforderlichen Wörterbücher und wird von [PropertiesContainer sharedInstance] aufgerufen.

Auf diese Weise müssen nicht alle Klassen, die Sie erwähnt haben, mit den einzelnen Klassen verbunden werden, um auf die Eigenschaften zuzugreifen. Jetzt haben Sie eine Klasse, auf die Sie leicht zugreifen können, wo immer Sie sie brauchen. (und es muss nicht wissen, wer es verwendet)

+0

danke. Ich habe noch nie 'sharedInstance' benutzt - muss darüber nachlesen. Es klingt, als wäre es konzeptionell klarer und wartungsfreundlicher als die Bizzaro-Art, in der ich jetzt arbeite. –

+0

Schau hier: http://iphone.galloway.me.uk/iphone-sdktutorials/singleton-classes/ – giorashc

+0

Scheint gut zu funktionieren!Nochmals vielen Dank –

1

Mithilfe des MVC-Musters können Sie ein Modellobjekt erstellen, das den gesamten Eigenschaftsbaum enthält, und den richtigen Teilbaum für jede Ansicht oder jeden Editor verwenden.

Das Model-Objekt muss nicht unbedingt als Singleton erstellt werden, nur die App muss genau eine (oder so viele wie nötig) erstellen und beibehalten.

+0

Aber ich würde in der gleichen Situation sein, wo ** RootView A ** es übergeben muss (oder eine Referenz an sich selbst oder selbst als Delegat gesetzt) ​​zu ** PropertyTableView B **, die es senden muss (oder sich selbst festlegen) als Delegat) zu ** PropertyDetailView C **, damit C auf die Liste der verfügbaren Optionen für diese bestimmte Eigenschaft zugreifen kann. Das bringt mich zurück in "self.delegate.delegate.dictionaryOfOptions" - sofern ich nicht falsch verstehe, was Sie meinen. –

+0

Wenn Sie die Eigenschaftendatenbank nicht außerhalb des Modells filtern müssen, müssen Sie nur dieses eine Model-Objekt zum Datenquellen-Delegaten für alles machen. – hotpaw2