Zugriff trotz Ringverweis

  • VB.NET

Es gibt 8 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    Zugriff trotz Ringverweis

    Moin!

    ich habe eine Klasse die Optionen innerhalb einer Programmumgebung zur Verfügung stellt.

    Dann habe ich eine Klasse die allgemeine Funktionen für interaktive Längenermittlungen etc.

    Die Optionsklasse hat einen Verweis auf die allgemeine um eben auch Parameter interativ ermitteln zu können.

    Nun gibt es aber in der allgemeinen Klasse ein Funktion die wiederum Parameter für den Betrieb genötigt und ich müßte also auch so einen Verweis aufbauen.

    Dieses würde einen Ringbezug bedeuten.

    Kann ich irgendwie auch einen Verweis nur auf einen Teil innerhalb einer DLL anlegen?

    Ansonsten müsste man das ganze ziemlich zerlegen und alles mögliche nachführen, testen, ....

    Gruß Jan

    jan99 schrieb:

    Dieses würde einen Ringbezug bedeuten.
    Ringbezug ist in meinem Verständnis, wenn eine Assembly A eine Assembly B referenziert, die wiederum die Assembly A referenziert.
    Wenn Du aus einer Klasse C eine statische Methode einer Klasse D aufrufst und wenn Du aus Klasse D eine statische Methode in Klasse C nutzt, ist das kein Ringverweis, solange die Prozeduren statisch sind.
    Und dann isses einfach etwas unlogisch zusammengesetzt.
    Pack die einfach in eine ghemeinsame Klasse, eine DLL ist dazu wohl nicht erforderlich.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Moin!

    soweit versehe ich auch - leider gibt es in dem gesamten Projekt eine Vielzahl von Einbindungen der oben genannten Klassen.

    Wenn ich das eine in das andere einbaue, dann muss ich an einer Vielzahl von Codestellen dieses anpassen - was wiederum zu potentiellen Fehlerquellen führen kann und das möchte ich gerne vermeiden.

    Ansonsten bleibt mir nur der Weg eine Zugriff-Funktionen aus den Optionen nochmals in der anderen Klasse zu definieren - was natürlich nicht so erstrebenswert ist.

    Gruß Jan

    jan99 schrieb:

    dann muss ich an einer Vielzahl von Codestellen dieses anpassen
    Das ist eine Frage der Organisation.
    Bei Zugriff über dynamische Variablen änderst Du den Typ, bei statischen Variablen änderst Du den Klassennamen, indem Du die Datei der Klasse umbenennst.
    Ich nenne so was "Aufräumen" und das geht ganz prima.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Mir würde keine elegante Lösung einfallen. Allerdings würde ich davon ausgehen, dass die Architektur ebenfalls nicht elegant gewählt ist, wenn die Komponenten gegenseitige Abhängigkeiten aufweisen und du das bei der Modellierung nicht berücksichtigt hast - sofern du das gemacht hattest.
    Holzhammermethode wäre, eine abstrakte Klasse/ein Interface zu erstellen, in dem du die Funktionalität abstrakt bereitstellst und gegenseitige Aufrufe ermöglichst.
    Für konkretere Vorschläge müsste man dann das Projekt detailliert kennen.

    Viele Grüße
    ~blaze~

    @jan99 Was hindert Dich daran, die betreffenden Prozeduren in eine gemeinsame Klasse zu packen?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

Facebook
Telefonspende