[VB 2005] Klassenentwurf - Zerstören von Objekten

09/10/2010 - 21:01 von Josef Morlo | Report spam
Hallo allerseits,

Ausgangssituation:

Ich habe ein Hauptformular, auf dem ich einige Zeichnungsobjekte mit der
Maus erstelle. Die Objektdaten lege ich in einer generischen Liste ab. Ich
habe eine zweite Klasse, die aufgrund der Liste Berechnungen anstellt, die
Werte der Zeichnungsobjekte nachjustiert und weitere ergànzende
Zeichnungsobjekte erstellt, die zusàtzlich auf meinem Hauptform
aktualisiert werden sollen. Dazu übergebe ich meiner Berechnungsklasse
einen Verweis auf mein Hauptform. Darüberhinaus gibt es noch weitere
Hilfsklassen. Das funktioniert auch soweit.

Probleme kriege ich dann, wenn ich mein Hauptform wieder in den
ursprünglichen 'blanken' Zustand zurückversetzen, die erstellten objekte
zerstören und einen neuen Arbeitsgang beginnen möchte.

Frage 1: Ist die Übergabe im beschriebenen Sinn überhaupt ein sinnvolles
Design, unabhàngig vom OOP-Kapselungsprinzip? So etwa:

Class SecondClass
Private WithEvents mForm as MainForm
Sub New (frm as Form)
mform = DirectCast(frm, MainForm)
End Sub
'Berechne und zeichne auf mForm
End Class

Frage 2: Wenn ich die erstellten Objekte in der umgekehrten Reihenfolge
ihrer Erstellung zerstöre ("myObject =nothing"), müsste ich doch in meinem
Hauptform wieder den Ausgangszustand herstellen können? Korrekt? Wenn ich
im Bilde bin, kann ein Objekt dann entsorgt werden, wenn kein Verweis mehr
auf es besteht. Korrekt?

Frage 3:
Wenn das nicht der Fall ist, und meine Zeichnungsobjekte (trotz invalidate)
fortbestehen, habe ich einen Verweis übersehen. Folgerung korrekt?

Ich hoffe, ich konnte das Problem trotz knapper und reichlich abstrakter
Skizze deutlich machen.

Danke für Beitràge und Grüße

Josef Morlo
 

Lesen sie die antworten

#1 Peter Fleischer
10/10/2010 - 08:28 | Warnen spam
"Josef Morlo" schrieb im Newsbeitrag
news:obcnddilwtdv$
...
Ich habe ein Hauptformular, auf dem ich einige Zeichnungsobjekte mit der
Maus erstelle.



Hi Josef,
unklar ist, wie die Objekte zur Anzeige kommen. Es gibt da mindestens 3
Wege:

1. einfach irgendwie "malen"
2. OnPaint überschreiben
3. Steuerlemente, die sich selbst malen, der Controls-Auflistung hinzufügen

...
Probleme kriege ich dann, wenn ich mein Hauptform wieder in den
ursprünglichen 'blanken' Zustand zurückversetzen, die erstellten objekte
zerstören und einen neuen Arbeitsgang beginnen möchte.



Es ist einfach das Zeichnen beim Refresh zu unterdrücken.

Frage 1: Ist die Übergabe im beschriebenen Sinn überhaupt ein sinnvolles
Design, unabhàngig vom OOP-Kapselungsprinzip? So etwa:

Class SecondClass
Private WithEvents mForm as MainForm
Sub New (frm as Form)
mform = DirectCast(frm, MainForm)
End Sub
'Berechne und zeichne auf mForm
End Class



Das ist nicht unbedingt optimal. Stell Dir vor, Deine SecondClass baut ein
anderer, der die MainForm-Klasse nicht hat.

Die eigentliche Paint-Routine, die bei jedem Refresh aufgerufen wird, sollte
sich in der MainForm-Klasse befinden. Ausgelagert werden in die SecondClass
kann die Verwaltung der Display-Liste. Die Verbindung zwischen beiden kann
über Interfaces und/oder Callback-Delegates organisiert werden.

Frage 2: Wenn ich die erstellten Objekte in der umgekehrten Reihenfolge
ihrer Erstellung zerstöre ("myObject =nothing"), müsste ich doch in meinem
Hauptform wieder den Ausgangszustand herstellen können? Korrekt? Wenn ich
im Bilde bin, kann ein Objekt dann entsorgt werden, wenn kein Verweis mehr
auf es besteht. Korrekt?



So ist es. Wenn Du aber in Deinen Objekten weitere Objekte nutzt, die
unmanaged Code kapseln, kann ein zusàtzliches Dispose erforderlich sein,
z.B. bei Nutzung der Pen-Klasse. Erst nach dem Dispose kann der Speicher
auch wirklich vollstàndig freigegeben werden, vorausgesetzt es liegen keine
Verweise mehr vor.

Frage 3:
Wenn das nicht der Fall ist, und meine Zeichnungsobjekte (trotz
invalidate)
fortbestehen, habe ich einen Verweis übersehen. Folgerung korrekt?



Wie bestimmst Du, dass die Objekt fortbestehen? Wenn Du keinen Verweis mehr
hast, dann kannst Du das auch nicht überprüfen. Den Speicher gibt der
Garbage Collector frei. Und dieser làuft aus der Sicht des Programmes
sporadisch asynchron, so dass u.U. erst sehr spàt über die Speichernutzung
die Freigabe erkannt werden kann.

Ich hoffe, ich konnte das Problem trotz knapper und reichlich abstrakter
Skizze deutlich machen.



Ohne konkretere Angaben (wie werden die Objekte in der Oberflàche "gemalt")
kann die Antwort nur sehr allgemein sein.

Viele Gruesse
Peter

Ähnliche fragen