Interface Designfrage

[KingR]

Also ich habe eine Komponente, welche auf Interfaces arbeitet. Da die andere GUI-Komponente, später ausgetauscht werden soll. Meine Interfaces stecken in einem eigenen Package und benutzen innerhalb ihrer Methoden Datenstrukturen aus meiner Komponente. Dadurch ensteht ein Zirkelbezug. Wie lässt sich der den sinnvoll auflösen??

 

[Giftstachel]

Mach mal bitte nen diagram. ist grade etwas verwirrend, was du genau meinst, bzw, wie man dir helfen kann, ohne das prog zu kennen..

also z.b.

main<-> IF <->GUI<->Main

prinzipiell würde ich sagen, das du alles über die main steuerst, und dort auch entsprechend die daten übergibst, bzw dir holst...

 

[SlaterB]

was heißt schon sinnvoll,
höre einfach damit auf, dass einer den anderen benutzt oder umgekehrt,

welchen Sinn hat es z.B., dass die Interface in einem eigenen package (Projekt?) liegen,
wenn sie doch wegen der Datenstrukturen eh nicht unabhängig vom anderen package sind,

lasse die Interfaces nur auf Interfaces der Datenstrukturen aufsetzen,
oder schiebe die Datenstrukturen zu den Interfaces oder in ein gemeinsames 3. package/ Projekt

 

[Marco13]

Die Beschreibung ist schon sehr dünn. Aber so Schlagworte wie "Model View Controller", "Observer" oder "Dependency Injection" kann ja mal ganz unverbindlich einstreuen ....

 

[KingR]

Also das ist die Struktur. Ich will verschiedene GUI Komponenten haben, die die Interfaces implementieren. Warum ein extra Package? Weil ich die Interfaces teil der GUI und nicht Teil des Controllers sind. Also die Interfaces sollen Datenstrukturen aus dem Controller übergeben werden. Was eindeutig ein Zirkelbezug ist, wie designt man den sowas.

 

[Wildcard]

Also die Interfaces sollen Datenstrukturen aus dem Controller übergeben werden. Was eindeutig ein Zirkelbezug ist, wie designt man den sowas.

Daten dürfen nicht wissen wie sie dem User präsentiert werden.

 

[KingR]

was meinst du damit?

 

[Wildcard]

Du schreibst das du dem dem Model Referenzen auf die GUI Schnittstellen geben willst.
Schlechtes Design.

 

[KingR]

Nein ich will der GUI Referenzen der Controller-Schicht geben...

 

[Wildcard]

Auch das ist nicht richtig. View und Model sind isoliert, Controller verbindet beide.

 

[SlaterB]

ich glaube darum ging es im ersten Posting,

da gibt es eine GUI-Komponente ViewA,
die verwendet Datenstrukturen wie ViewDataA (zum Informationsaustausch mit Controller oder wer immer die Daten übergibt, weiß ViewA nicht),

der Controller soll nun aber nicht direkt mit ViewA zusammenarbeiten, da ViewA später noch gegen ViewB ausgetauscht wird,

also muss ein Interface ViewI her,
ViewI verwendet aber bisher ViewDataA (als Parameter oder Rückgabewert),
diese Abhängigkeit soll aufgelöst werden

 

[ARadauer]

View und Model sind isoliert, Controller verbindet beide.

ich denke es spricht nichts dagegen wenn eine view eine referenz auf das model hat und dad model über observer direkt das view informieren kann.

 

[Wildcard]

ich denke es spricht nichts dagegen wenn eine view eine referenz auf das model hat und dad model über observer direkt das view informieren kann.

Im Prinzip ist es sauberer wenn der Controller als Listener fungiert und den Zustand der View ändert (da die View dann theoretisch auch andere Modells abbilden kann), aber auch die von dir genannte Möglichkeit ist valide und wurde von mir auch schon verwendet.