Objekt in globaler Variable

@macmarvin
Danke für den Hinweis, habe ich in diesem momentan nicht daran gedacht.
Könntest Du dich zu meiner Antwort auf dein erstes Post äußern?

Zitat:Vielen dank erst mal.
Vielleicht kurz beschrieben was mein Ziel ist, eventuell gibt es eine noch bessere Umsetzung.
Ich habe, sagen wir mal ein großes über die Jahre gewachsenes Programm.
Um am Prüfstand (nur exe installiert) sporadisch auftretende Fehler besser untersuchen zu können, will ich eine Klasse die mir einfach eine Log-Datei schreibt.

Ich habe mir das wie folgt vorgestellt:
Klasse log welche als Eigenschaft den Dateinamen der LogDatei hat, eine Init Funktion und viele verschiedene Schreibmethoden für String, Integer, Double, verschiedenen Arrays, ...
Damit ich das Klassen Objekt nicht durch die ganzen Vis von oben nach unten verdrahten muß, kam mir die Idee mit der globalen Variablen vom Objekt selbst, was wohl nicht ganz so gut ist.
Wenn ich jetzt DVR verwende und es richtig verstanden habe, würde ich mir in der Init Funktion eine Refrenz vom Objekt erstellen und diese in einer globalen Variablen ablegen und alle Member Funktionen der Klasse würden dann intern nur mit dieser Referenz arbeiten anstatt dem Objekt selbst.
Ist dies so richtig, bzw verständlich was ich meine?

FGV sagt mir leider gar nichts.
Nach kurzem googlen kann ich mir darunter etwas vorstellen jedoch ist mir nicht ganz klar wie ich dies hier einsetzen soll?
War gemeint das Objekt in dem FGV VI zu erstellen und für jeder Memberfunktion ein Case in der FGV zu erstellen?
Wenn dies der Fall ist kann ich mir das OOP doch gleich sparen, oder nicht?

Habe eigentlich schon vor dies in einer Klasse zu lösen. Allerdings nur wenn ich weiß ob dies mit der Referenz in der Klasse kein Problem ist.


@<<oenk>>
Danke für den Hinweis, werde mir GOOP mal anschauen.
Das mit der Treibergeschichte sehe ich auch so, und steht mir auch noch bevor hier sinnvoll neu zu strukturieren.
Das heißt deine Empfelung ist GOOP statt LVOOP.
Eventuell werde ich mich zu deiner, ich nenn es jetzt mal Treiberarchitektur noch melden.

MfG Stephan

Anzeige

(20.06.2012 11:10 )Y-P schrieb:  Wenn du schon objekt orientiert programmieren kannst, dann empfehle ich GOOP. Das kommt der OOP IMHO am nächsten, da mit Objekten gearbeitet wird (by Reference). GOOP4 kapselt die Objekte in DVRs, was das ganze auch um einiges performanter macht als mit GOOP3 Klassen.

Mit DVR kann man sich aber auch üble Verklemmungen (Deadlocks) einhandlen! Also besser Datenfluss!

Gruß Holger

Deine LogKlasse ist ein klassisches Singleton Objekt. Das kann man zwar mit LVOOP auch machen aber ist meiner Meinung nach etwas Overkill. Die meist direkte Umsetzung eines Singleton Objekts ist meiner Ansicht nach eine FGV. Und solange die Anzahl der Methoden überschaubar bleibt ist es auch die einfachste Variante. Das Ganze kann man dann auch noch in Accessor VIs einpacken die die jeweiligen Methoden aufrufen. Wenn man das alles noch in eine LVLIB packt und nur die Accessor VIs als Public definiert kommt man einem LVOOP Singleton Objekt sehr nahe.

Wenn ich mich recht erinner gabs dazu auch mal so nen Design Pattern PDF für LVOOP in dem Stephen Mercer auf verschiedene aus anderen OOP Sprachen eingegangen ist und umsetzungen in Labview angesprochen hat (unter anderem den Singleton). Hab dazu auch noch den Link hier gefunden, falls du noch weitere Anregungen für die Implementation suchst: https://decibel.ni.com/content/docs/DOC-13462

Gruß Kiesch