Laden...

Objekt aus Hauptklasse auch in Nebenklassen verwenden

Erstellt von C-sharper96 vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.207 Views
C
C-sharper96 Themenstarter:in
4 Beiträge seit 2019
vor 4 Jahren
Objekt aus Hauptklasse auch in Nebenklassen verwenden

Hallo liebe Community

Ich stehe hier gerade vor einem Problem, für welches ich einfach keine Antworten finde X(
Wahrscheinlich hab ich einfach nur einen Wurm oder so in meinem Gedankengang.

Was ich habe:

  • Hauptklasse (steht wegen einer Umstrukturierung des Programmes nicht viel drin)
  • 3 Nebenklassen/DLLs
    • erste baut einen Bus auf.
    • zweite liest den Bus ein und erstellt einen neuen, mit anderen Attributen, aber in der gleichen
      Struktur
    • dritte liest beide vorherigen Busse aus und wertet die nötigen Informationen aus.

[csharp]
using DLL_A;
using DLL_B;
using DLL_C;
namespace Hauptprogramm
{
.
.
.
        public void Main()
        {
            Bus BusObject;
            dllA.Write(ref BusObject)
            dllB.ReadWrite(ref BusObject)
            dllC.Read(ref BusObject)
        }
    }
    public class Bus
    {
         //Hier stehen alle Attribute
    }
}
[/csharp]


[csharp]
using Assemblys_für_das_jeweilige_Programm
namespace DLL_A
{
.
.
.
        public void Write( N/A ) <- Hier brauch ich ja jetzt den Typen Bus... sowie bei den anderen auch.
.
.
.
}
[/csharp]

Was ich möchte:

Ein Objekt welches in der Hauptklasse erzeugt wird und in DLL 1 und 2 dessen Attribute beschrieben/definiert werden. In der 3. DLL soll das fertig definierte Objekt dann ausgelesen werden.

Nur komme ich einfach nicht drauf...

Mit freundlichen Grüßen

16.806 Beiträge seit 2008
vor 4 Jahren

Im Prinzip ist das Software Architektur; les Dich mal in den Bereich ein.
[Artikel] Drei-Schichten-Architektur ist die am meisten verbreitete dazu.

Wenn Dir diese Konzepte fehlen, dann wird es sehr schwer Software zu entwickeln.

3.003 Beiträge seit 2006
vor 4 Jahren

Ich ignoriere die, äh, unkonventionelle Bezeichnung "Nebenklasse" und "Hauptklasse" und fasse mal zusammen:

du hast drei voneinander unabhängige Klassen, die jeweils etwas mit einem Objekt des Typs "Bus" machen. Außerdem hast du noch eine Kontextklasse, die diese drei Klassen orchestriert (i.e. aufruft und die Reihenfolge der Aufrufe und damit das Ergebnis bestimmt).

Der Kontext braucht also Referenzen auf jede der benutzten Klassen. Soweit alles richtig bei dir.
Allerdings müssen die drei benutzten Klassen auch die Klasse "Bus" kennen. Die definierst du allerdings im Kontext, von dem die DLL_* nix wissen.

Nebenbei bemerkt, ist die Nutzung von "ref" in dem Kontext schlicht falsch, und auch die Benutzung von statischen Methoden willst du dir lieber abgewöhnen.

Also lieber so:


namespace Abstractions
{
   public class Bus 
  {
      public string Name { get; set; }
  }
}

namespace DLL_A 
{
  using Abstractions;
   public class Writer 
  {
      Write(Bus bus) { bus.Name = "Wert1"; }
  }
}
namespace DLL_B
{
  using Abstractions;
   public class ReadWriter
  {
      ReadWrite(Bus bus) { Console.WriteLine(bus.Name); bus.Name = "Wert2"; }
  }
}

namespace DLL_C
{
  using Abstractions;
   public class Reader
  {
      Read(Bus bus) { Console.WriteLine(bus.Name); }
  }
}

namespace Hauptprogramm
{
  using Abstractions;
  using DLL_A;
  using DLL_B;
  using DLL_C;
 
  public class Context 
  {
    public static void Main() 
    {
        Writer writer = new Writer();
        ReadWriter readWriter = new ReadWriter();
        Reader reader = new Reader();
        Bus myBus = new Bus();
        writer.Write(bus);
        readWriter.ReadWrite(bus);
        reader.Read(bus);
    }
  } 
}

Wobei mir generell nicht einleuchtet, wieso die Klassen alle in unterschiedlichen Namespaces sein müssen. Ich gehe aber mal davon aus, dass du dir dabei was gedacht hast.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

709 Beiträge seit 2008
vor 4 Jahren

Ich tippe mal, dass du Properties und keine Attribute meinst.

C
C-sharper96 Themenstarter:in
4 Beiträge seit 2019
vor 4 Jahren

Im Prinzip ist das Software Architektur; les Dich mal in den Bereich ein.

>
ist die am meisten verbreitete dazu.

Danke, sehr interessant, werde ich mir definitv anschauen. 👍

Wenn Dir diese Konzepte fehlen, dann wird es sehr schwer Software zu entwickeln.

Ich ignoriere die, äh, unkonventionelle Bezeichnung "Nebenklasse" und "Hauptklasse"
[...]
Nebenbei bemerkt, ist die Nutzung von "ref" in dem Kontext schlicht falsch, und auch die Benutzung von statischen Methoden willst du dir lieber abgewöhnen.

Ich tippe mal, dass du Properties und keine Attribute meinst.

Bin leider erst seit ~6 Monaten in der Informatik tätig, weswegen mir meist die Fachbegriffe fremd sind oder ich die vertausche 🙁
Das meiste hab ich mir bis dato selber beigebracht, wobei viele Dokumentationen nicht sonderlich Einsteigerfreundlich geschrieben sind. Also meiner Meinung nach.
Aber danke für die Tipps! 👍

Also lieber so:

Vielen Dank! 👍
Das macht Sinn 🤔 Aber soweit habe ich gar nicht gedacht.
Werde das definitiv so ausprobieren.

4.931 Beiträge seit 2008
vor 4 Jahren

Aber warum hast du überhaupt 3 verschiedene DLLs mit jeweils ähnlicher Funktionalität???

C
C-sharper96 Themenstarter:in
4 Beiträge seit 2019
vor 4 Jahren

Aber warum hast du überhaupt 3 verschiedene DLLs mit jeweils ähnlicher Funktionalität???

Bei dem Programm handelt es sich um ein Bindeglied/Schnittstelle zwischen 3 verschiedenen Programmen. Deswegen liegen jedem Programm eine eigene API zugrunde auf die ich alle zugreifen soll. Das ganze möchte ich natürlich getrennt voneinander stattfinden lasse.

API 1 liest schlichtweg dynamisch das gewählte Project aus und stellt die Topologie in einer n-ary-Baumstruktur? dar. Zusätzlich werden hier die notwendigen Assemblys versionsabhängig geladen durch einen Assembly-Loader. Bei den anderen ist so etwas nicht notwendig.

API 2 braucht dann die Struktur und ein paar Eigenschaften um in dem zweiten Programm quasi die gleiche Topologie zu erstellen.

API 3 benötigt dann alle Informationen die sich erst durch das erstellen in API 2 ergeben haben und die restlichen von API 1 um alles miteinander zu verknüpfen.

16.806 Beiträge seit 2008
vor 4 Jahren

Das meiste hab ich mir bis dato selber beigebracht, wobei viele Dokumentationen nicht sonderlich Einsteigerfreundlich geschrieben sind. Also meiner Meinung nach.

Es macht auch keinen Sinn jede Dokumentation so zu gestalten, dass kein Basiswissen vorhanden ist.
Dokumentationen werden so geschrieben, dass es um das spezifische Problem geht: man kommt sachlich auf den Punkt.

Wenn da Vorwissen fehlt dann meist deswegen, weil "einfach mal drauf losgelegt" hat statt einen Lernpfad zu gehen.