myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Entwicklung » Grundlagen von C# » Wie kann ich ein vorliegendes (UML) Klassendesign implementieren?
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

Wie kann ich ein vorliegendes (UML) Klassendesign implementieren?

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
Saftsack
myCSharp.de-Mitglied

Dabei seit: 11.03.2018
Beiträge: 12


Saftsack ist offline

Wie kann ich ein vorliegendes (UML) Klassendesign implementieren?

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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! :)

Saftsack hat dieses Bild (verkleinerte Version) angehängt:
klassendiagramm.png
Volle Bildgröße

24.09.2019 17:35 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
gfoidl gfoidl ist männlich
myCSharp.de-Team

avatar-2894.jpg


Dabei seit: 07.06.2009
Beiträge: 6.651
Entwicklungsumgebung: VS 2019
Herkunft: Waidring


gfoidl ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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ü
24.09.2019 18:23 Beiträge des Benutzers | zu Buddylist hinzufügen
Saftsack
myCSharp.de-Mitglied

Dabei seit: 11.03.2018
Beiträge: 12

Themenstarter Thema begonnen von Saftsack

Saftsack ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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..
24.09.2019 18:46 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
gfoidl gfoidl ist männlich
myCSharp.de-Team

avatar-2894.jpg


Dabei seit: 07.06.2009
Beiträge: 6.651
Entwicklungsumgebung: VS 2019
Herkunft: Waidring


gfoidl ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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ü
24.09.2019 20:06 Beiträge des Benutzers | zu Buddylist hinzufügen
Coder007
myCSharp.de-Mitglied

Dabei seit: 05.08.2006
Beiträge: 1.209


Coder007 ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von Saftsack:
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.
24.09.2019 20:36 Beiträge des Benutzers | zu Buddylist hinzufügen
fichz fichz ist männlich
myCSharp.de-Mitglied

Dabei seit: 15.01.2013
Beiträge: 13
Entwicklungsumgebung: VS 2013 Prof, 2019 Community
Herkunft: Linz


fichz ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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

Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von fichz am 25.09.2019 09:50.

25.09.2019 09:50 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Saftsack
myCSharp.de-Mitglied

Dabei seit: 11.03.2018
Beiträge: 12

Themenstarter Thema begonnen von Saftsack

Saftsack ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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:

C#-Code:
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

Saftsack hat dieses Bild (verkleinerte Version) angehängt:
ppereq.png
Volle Bildgröße

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Saftsack am 25.09.2019 11:42.

25.09.2019 11:37 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 13.835
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.

C#-Code:
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:

C#-Code:
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.
25.09.2019 11:51 Beiträge des Benutzers | zu Buddylist hinzufügen
Saftsack
myCSharp.de-Mitglied

Dabei seit: 11.03.2018
Beiträge: 12

Themenstarter Thema begonnen von Saftsack

Saftsack ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
25.09.2019 12:05 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
gfoidl gfoidl ist männlich
myCSharp.de-Team

avatar-2894.jpg


Dabei seit: 07.06.2009
Beiträge: 6.651
Entwicklungsumgebung: VS 2019
Herkunft: Waidring


gfoidl ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo Saftsack,

Zitat:
"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ü
25.09.2019 16:07 Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 8 Monate.
Der letzte Beitrag ist älter als 8 Monate.
Antwort erstellen


© Copyright 2003-2020 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 05.06.2020 18:11