Laden...

Wie kann ich ein vorliegendes (UML) Klassendesign implementieren?

Erstellt von Saftsack vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.343 Views
S
Saftsack Themenstarter:in
12 Beiträge seit 2018
vor 4 Jahren
Wie kann ich ein vorliegendes (UML) Klassendesign implementieren?

Hallo zusammen,
da ich bei meinem ersten Ansatz eine Klassbibliothek aufzubauen gnadenlos gescheitert bin, wollte ich jetzt mal euren Rat einholen, wie man methodisch am besten vorgeht, wenn man bspw. ein Objektmodell schon vorliegen hat und dieses dann implementieren muss.
Ich habe euch mal ein typisches Klassendiagramm aus meiner "Vorlage" als Bild angehangen.
Die komplette Beschreibung des Modelles findet ihr hier:
https://www.plt.rwth-aachen.de/cms/PLT/Forschung/Projekte2/~ejwz/PandIX/

Ich bin euch für gute Ratschläge sehr dankbar! 😃

6.911 Beiträge seit 2009
vor 4 Jahren

Hallo Saftsack,

wo hängst du denn?

Ich tu mir schwer eine andere Antwort zu schreiben, da das Klassendiagramm vorliegt und es für mich in Code zu gießen nicht schwer ist.
Den Code einfach posten bringt dir nicht viel -- zumindest hast du wenig Lerneffekt dabei.

Schau dir dazu auch UML-Klassendiagramm an, vllt. ergibt sich dann schon ein besseres Bild für dich.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

S
Saftsack Themenstarter:in
12 Beiträge seit 2018
vor 4 Jahren

Danke ja ich weiß, ich bin bei meinem ersten Versuch bei "Design Pattern" hängen geblieben - sprich ich bin mir nicht sicher, ob ich irgendwelche "speziellen" Methoden anwenden soll, wie Factory Method, Dependency Injection o.Ä. .. also wann es Sinn macht bestimmte Konzepte zu implementieren...also mir fehlen die Entscheidungshilfen:
Wann nehme ich eine Factory?
Wann nehme ich ein Dependency Incjenction?
Ich habe schon festgestellt, dass eine Factory eigentlich nur Sinn macht, wenn man eine Klasse mit gleichen Methoden und Properties hat und verschiedene "Varianten" davon implementieren will. Aber wie verhält sich das z.B. wenn ich 2 Klassen habe..die das gleiche Interface implementieren, nur, dass eine Klasse ein Property mehr hat...dafür hatte ich eine Factory versucht zu erstellen - aber logischerweise kann das Interface nur die Properties und Methoden aufnehmen, die in ihr definiert sind....ich möchte halt C# vernünftig lernen und anwenden und keine "Fummel-Lösungen" entwickeln..

6.911 Beiträge seit 2009
vor 4 Jahren

Hallo Saftsack,

deine Herangehensweise ist auch vernüftig. Dennoch tue ich mir schwer eine Antwort zu verfassen, wie du sie vllt. erwartest. Bzgl. Patterns ist es oft auch schwierig eine pauschale Antwort zu geben, wie "nimm eine Factory, falls...". Um so etwas zu beurteilen, müsste das größere Bild der zu erstellenden Anwendung / Komponente bekannt sein.

Schau dir dazu die ersten Treffer von Google-Suche nach c# design patterns an. Da gibt es ein paar ganz gute Erklärungen mit Beispielen.

Letztlich ergeben sich solche Entscheidungen von alleine wenn die Erfahrung wächst. Da gehört es auch dazu, sich ein paar mal zu verennen -- aber aus Fehlern lernt man (hoffentlich).

Zum Lernen von Klassenhierarchien ist das oben angehängte Klassendiagramm schon brauchbar, für das Lernen von C# und Design Pattern kommt es mir nicht so ideal vor.
Orientiere dich da eher an [FAQ] Wie finde ich den Einstieg in C#? und mach einfache Beispiel-Programme, die dann schrittweise mit den Pattern ergänzt werden. Schau dir da auch unbedingt automatisierte Tests (v.a. Unit-Tests) an, denn durch die Testbarkeit machen manche Pattern mehr sinn, da sonst eben nicht getestet werden kann.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

C
1.214 Beiträge seit 2006
vor 4 Jahren

sprich ich bin mir nicht sicher, ob ich irgendwelche "speziellen" Methoden anwenden soll, wie Factory Method, Dependency Injection o.Ä. .. also wann es Sinn macht bestimmte Konzepte zu implementieren...

Ich finde, das sind in dem Sinne nicht-funktionale Anforderungen. Also, eigentlich hätte ich sie schon als funktionale Anforderungen eingestuft, aber es geht aus der Spezifikation einfach nicht hervor. Von dem her kann man das so interpretieren, dass das völlig egal ist, so lange die dargestellte Funktionalität erfüllt ist.

Aber in einem richtigen System würde es von vielen weiteren Faktoren abhängen. Wir haben bei uns z.B. auch ein recht zentrales "Pipeline" System. Das ist zwar wahrscheinlich ziemlich anders, als das was von dir gefordert ist, dürfte aber prinzipiell auch eine gewisse Ähnlichkeit aufweisen.
Und sehr vieles ergibt sich da eben aus den Anforderungen und der Umgebung. Wir arbeiten z.B. mit C++, d.h. da geht man schon mal oft anders vor, als in C# oder Java, z.B. bei der Frage nach der Factory. Und das ist bei uns schon eine wichtige Frage, die mit vielen anderen Faktoren zusammenhängt.
Auch wie die Pipeline auszuführen ist, geht aus deinem Diagramm nicht hervor. Das ist bei uns z.B. auch eine ganze Menge Code, der sich in den letzten Jahren massiv weiterentwickelt hat, und wo wir viel gelernt haben. Oder wie der Datenaustausch zwischen den Knoten ausschaut.

Da kommen in einer richtigen Software einfach noch sehr viel mehr Fragen auf, die die Designentscheidungen dann massiv beeinflußen.

F
26 Beiträge seit 2013
vor 4 Jahren

Bezüglich Design-Pattern stieß ich einmal auf diese Seite, wo wie ich finde einige Pattern sehr gut am Beispiel erklärt werden:

https://www.philipphauer.de/study/se/design-pattern.php

Vielleicht hilft es dir.

LG

S
Saftsack Themenstarter:in
12 Beiträge seit 2018
vor 4 Jahren

Erstmal vielen Dank für eure Ratschläge. Also wenn ich das jetzt "runter" Programmieren würde, würde ich vermutlich erstmal nur mit Interfaces hantieren um die hierarchische Struktur abzubilden..und dann jede einzelne Klasse für die ein Interface besteht implementieren. Aber ist das "good practice"?

Z.B: könnte ich es ja so implementieren:

public interface PPERequestBase{}
public interface PipeRequestBase : PPEReqestBase{}
public interface PipeJunctionBase : PPERequestBase{}
...

public interface Interfaces{}
public interface ProductInterface : Interfaces{}
public interface ProductConnectionPoint : ProductInterface {}
....
public interface PPERequestBase : PPERequestBase, Interfaces {}
public interface PipeRequestBase : PipeRequestBase, Interfaces {}

usw...
aber das generiert natürlich eine Menge Code - der vllt gar nicht nötig ist

16.807 Beiträge seit 2008
vor 4 Jahren

Das ist kein UML Diagramm. Was soll das sein?
Im Sinne von C# stimm hier auch der Sprachgebrauch nicht. Attribute sind was anderes in C#.

Das mit den Interfaces macht so keinen Sinn.

public interface Interfaces{}
public interface ProductInterface : Interfaces{}

Würde man ohnehin so weder machen noch so nennen.

Wenn ich das jetzt einigermaßen richtig verstehe:

public interface IPPERequest
{
   
}

public class MeasurementPoint : IPPERequest
{
}

Was mich stutzog macht ist das "interface" Label in der Ansicht und die Relationshinweise in Form von * oder "0..1".
Das sieht fast eher nach einer Datenbankstruktur statt nach einer OOP Struktur aus.

S
Saftsack Themenstarter:in
12 Beiträge seit 2018
vor 4 Jahren

Hallo ja die nennen das hier in der Veröffentlichung allgemein "Objektmodell" - Interfaces sind hier "Schnittstellenelemente" und haben mit den Interfaces in c# nichts zu tun

Die Idee hinter dem Modell ist bspw. eine Rohrleitung als ein Objekt zu sehen mit einem Auslasspunkt und einen Einlasspunkt: Diese Punkte werden unglücklicherweise als Interfaces bezeichnet, gemeint sind aber Übergabepunkte zu anderen Elementen, z.B.: einem Reduzierstück, die dann wiederum ein Eingangspunkt und einen Ausgangspunkt haben. Etwas abstrakter bezeichnen diese "Interfaces" Punkte, wo Objekte in einer Beziehung mit ihrer Umgebung stehen.

6.911 Beiträge seit 2009
vor 4 Jahren

Hallo Saftsack,

"Interfaces" Punkte, wo Objekte in einer Beziehung mit ihrer Umgebung stehen.

Das passt auch und ist zu verwechseln mit dem C# Schlüsselwort interface.
Auch eine abstrakte Klasse kann ein Interface sein, genauso wie ein interface od. eine Methode -- je nachdem wie es betrachtet wird.
Lass dich davon nicht beirren.

Irgendwo brauchst du auch eine konkrete Ausprägung eines Interfaces. Schau dir dazu Abts Beispiel an.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"