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# » Klasse mit gekapselten Variablen in XML serialisieren - Programmierstil
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

Klasse mit gekapselten Variablen in XML serialisieren - Programmierstil

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
EyeTrackJack EyeTrackJack ist männlich
myCSharp.de-Mitglied

Dabei seit: 24.01.2019
Beiträge: 20
Entwicklungsumgebung: Visual Studio


EyeTrackJack ist offline

Klasse mit gekapselten Variablen in XML serialisieren - Programmierstil

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

Hallo,

ich möchte gerne eine Klasse definieren, die die Parameter für eine Schaltfläche enthält, die mit einem Eyetracker betätigt wird. Da soll gespeichert werden: Farbe, Position, ein Tastaturcode, der gesendet wird, den Namen der Schaltfläche etc.

Das ganze soll dann in XML serialisierbar sein, damit ich diese Einstellungen leicht lesen und schreiben kann. Aber im Widerspruch steht, dass man doch Variablen kapseln soll.

Wie löse ich das? Verzichte ich in dem Fall auf die Kapselung und deklariere die Variablen als Public? Oder was ist der richtige Weg?

Grüße

Tobias K
Neuer Beitrag 25.01.2019 20:35 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
trashkid2000 trashkid2000 ist männlich
myCSharp.de-Mitglied

Dabei seit: 27.12.2010
Beiträge: 156


trashkid2000 ist offline

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

Hi,

Du könntest einen Custom-Serializer/ Deserializer erstellen, der dann aus privaten Feldern die Daten in die XML schreibt bzw. aus dieser in die privaten Felder schreibt.

Gruß, Marko
Neuer Beitrag 25.01.2019 22:07 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
EyeTrackJack EyeTrackJack ist männlich
myCSharp.de-Mitglied

Dabei seit: 24.01.2019
Beiträge: 20
Entwicklungsumgebung: Visual Studio

Themenstarter Thema begonnen von EyeTrackJack

EyeTrackJack ist offline

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

Hi,

Ich habe auch schon daran gedacht, aber ich möchte vermeiden, mich da um jeden Parameter einzeln kümmern zu müssen. Würde schon gerne einfach alles auf einen Schlag serialisieren.

Heißt das, dass der korrekte Weg nur über eine vollständige Kapselung läuft, auch wenn das viel mehr Arbeit ist? Weil mein Weg in einem anderen Programm gut funktioniert hat. Mein Ziel besteht aber schon darin, den korrekten Weg zu können.

Grüße

Tobias
Neuer Beitrag 25.01.2019 23:40 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Th69
myCSharp.de-Poweruser/ Experte

avatar-2578.jpg


Dabei seit: 01.04.2008
Beiträge: 3.412
Entwicklungsumgebung: Visual Studio 2015/17


Th69 ist offline

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

Benutze doch Eigenschaften (properties) dafür:

C#-Code:
public string Name { get; set; }

Und wenn du dafür eine eigene (Daten-)Klasse erstellst, dann hast du ja Kapselung erreicht.
Neuer Beitrag 26.01.2019 07:40 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
T-Virus T-Virus ist männlich
myCSharp.de-Mitglied

Dabei seit: 17.04.2008
Beiträge: 1.367
Entwicklungsumgebung: Visual Studio, Codeblocks, Edi
Herkunft: Nordhausen, Nörten-Hardenberg


T-Virus ist offline Füge T-Virus Deiner Kontaktliste hinzu

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

@trashkid2000
Sowas macht man nicht.
Dafür gibt es, wie Th69 schon sagt, einfach Eigenschaften.
Diese stellen dann die öffentlichen Felder zum De-/Serailisieren dar.

@EyeTrackJack
Zum De-/Serialisieren von/nach XML gibt es in C# fertige Lösungen.
Im Link findest du dazu eine gute Einleitung.

Link:
 https://docs.microsoft.com/de-de/dotnet/...l-serialization

T-Virus

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von T-Virus am 26.01.2019 10:22.

Neuer Beitrag 26.01.2019 10:20 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
EyeTrackJack EyeTrackJack ist männlich
myCSharp.de-Mitglied

Dabei seit: 24.01.2019
Beiträge: 20
Entwicklungsumgebung: Visual Studio

Themenstarter Thema begonnen von EyeTrackJack

EyeTrackJack ist offline

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

Danke für die Antworten. Dann werde ich mit den Eigenschaften arbeiten.

Wobei sich für mich beides etwa gleich anfühlt:

C#-Code:
public int Feld1{ get; set; } = 100;
public int Feld2 = 100;

Wegen dem Verständnis frage ich mal so platt, wieso ist das eine besser?

Grüße

Tobias
Neuer Beitrag 28.01.2019 22:13 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
trashkid2000 trashkid2000 ist männlich
myCSharp.de-Mitglied

Dabei seit: 27.12.2010
Beiträge: 156


trashkid2000 ist offline

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

Zitat von T-Virus:
@trashkid2000
Sowas macht man nicht.
Dafür gibt es, wie Th69 schon sagt, einfach Eigenschaften.

Die dann aber auch public get set sein müssen...
Deswegen lasse ich es nicht so einfach stehen.
Und ja, manchmal ist für Sicherheit auch (viel) Mehraufwand nötig.
Neuer Beitrag 28.01.2019 23:08 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.266
Herkunft: Stuttgart/Stockholm


Abt ist offline

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

Zitat von trashkid2000:
Deswegen lasse ich es nicht so einfach stehen.

Trotzdem hat T-Virus Recht: dafür gibt es Eigenschaften.
Ein Custom Serializer ist der vollkommen falsche Weg.

Das Grundproblem ist, dass hier offensichtlich der Beschreibung nach keine Schichtentrennung erfolgt.
Es werden also Klassen zum Speichern verwendet, die UI- oder Businessmodelle darstellen. Eine Klasse, die nur für das Speichern und Lesen verwendet wird, hat i.d.R. keine Felder - sondern nur Eigenschaften.
 [Artikel] Drei-Schichten-Architektur
Die Frage würde sich also bei einem saubererem Software Design nicht stellen.

Und private Elemente zu serialisieren gehört nicht nur zum Code Smell sondern ist Bad Practise. Sinnvoll nur in absoluten Ausnahmefällen ;-)

Zitat von EyeTrackJack:
Wegen dem Verständnis frage ich mal so platt, wieso ist das eine besser?

Ein Grundgedanke von OOP ist, dass die interne Umsetzung einer Klasse von Aussen nicht ersichtlich sein soll.
Das kannst Du mit einer Eigenschaft erreichen, aber nicht mit einem Feld.

Ein Feld ist nur ein "dummes" Klassenmember; also eine Variable.
Eigenschaften sind jedoch Abstraktionen; Du kannst beim Setzen (oder Lesen) noch zusätzliche Dinge tun (zB Lazy Loading, Events feuern..) - was bei einem Feld nicht geht.

Wenn Dir das alles neu ist, dann lohnt sich mind. 1 Tag Investition in die Doku ungemein  Eigenschaften (C#-Programmierhandbuch)
Und zur Korrektur:

C#-Code:
public int Eigenschaft { get; set; } = 100;
public int Feld = 100;
Neuer Beitrag 28.01.2019 23:55 Beiträge des Benutzers | zu Buddylist hinzufügen
trashkid2000 trashkid2000 ist männlich
myCSharp.de-Mitglied

Dabei seit: 27.12.2010
Beiträge: 156


trashkid2000 ist offline

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

Wenn Du Json.NET benutzt,
gibt es da noch die Möglichkeit von private Setters:

C#-Code:
[JsonProperty]
public Guid? ClientId { get; private set; }

Nur mal so als Anregung smile

// Edit: jaa...
XML und kein JSON... passt dann gar nicht

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von trashkid2000 am 29.01.2019 22:36.

Neuer Beitrag 29.01.2019 22:30 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
trashkid2000 trashkid2000 ist männlich
myCSharp.de-Mitglied

Dabei seit: 27.12.2010
Beiträge: 156


trashkid2000 ist offline

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

Sorry,
@Abt

Zitat von Abt:
Das Grundproblem ist, dass hier offensichtlich der Beschreibung nach keine Schichtentrennung erfolgt.
Es werden also Klassen zum Speichern verwendet, die UI- oder Businessmodelle darstellen.

Bzw. Businesslogik enthalten. Ja, da gebe ich Dir Recht. Das ist nicht gut.
Die DataModel-Schicht (Infrastructure, oder wie auch immer) soll also nur dumm sein. Und Daten halten.
Und im besten Fall die Daten nicht einfach von "außen" modifizierbar machen.

Zitat von Abt:
Ein Feld ist nur ein "dummes" Klassenmember; also eine Variable.
Eigenschaften sind jedoch Abstraktionen; Du kannst beim Setzen (oder Lesen) noch zusätzliche Dinge tun (zB Lazy Loading, Events feuern..) - was bei einem Feld nicht geht.

Das beißt sich meiner Meinung nach mit Schichtentrennung und dumme Datenklasse Augenzwinkern
Neuer Beitrag 29.01.2019 22:50 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
ThomasE. ThomasE. ist männlich
myCSharp.de-Mitglied

avatar-178.gif


Dabei seit: 26.11.2013
Beiträge: 446
Entwicklungsumgebung: Visual Studio 2015Pro/2017Ent


ThomasE. ist offline

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

Zitat von trashkid2000:
Zitat von Abt:
Ein Feld ist nur ein "dummes" Klassenmember; also eine Variable.
Eigenschaften sind jedoch Abstraktionen; Du kannst beim Setzen (oder Lesen) noch zusätzliche Dinge tun (zB Lazy Loading, Events feuern..) - was bei einem Feld nicht geht.

Das beißt sich meiner Meinung nach mit Schichtentrennung und dumme Datenklasse ;)

Das sehe ich nicht so.

Ist klar, C# erlaubt dir soweit alles in der Richtung, nur hängt es vom Programmierer ab, ob er sich an gewisse Regeln hält und somit ein stabiles sicheres System zu erstellen.

Klar kannst du das alles machen und noch mehr, nur ist es weit von einer sauberen Lösung entfernt.

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von ThomasE. am 30.01.2019 08:09.

Neuer Beitrag 30.01.2019 08:08 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.266
Herkunft: Stuttgart/Stockholm


Abt ist offline

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

Zitat von trashkid2000:
gibt es da noch die Möglichkeit von private Setters:

Hab gewartet (und ein bisschen gewusst), dass das kommt - kenne natürlich auch Json.NET sehr gut.. :-)
.. und weil jetzt eine Bibliothek das unterstützt, gilt das als allgemein okay? Leider nicht.
Auch in Json.NET ist dies ein Workaround, um bestimmte Szenarien zu supporten - aber sicher keine allgemeine Empfehlung!

Das Gegenteil ist sogar der Fall: die meisten Serializer unterstützen keine Felder; vor allem keine privaten; sondern nur public Properties.

Zitat von trashkid2000:
Und im besten Fall die Daten nicht einfach von "außen" modifizierbar machen.

.. was mit einer Eigenschaft funktioniert - aber nicht mit einem Feld.

Zitat von trashkid2000:
Sorry,
Das beißt sich meiner Meinung nach mit Schichtentrennung und dumme Datenklasse ;)

Respektiere ich; verweise Dich an der Stelle dann doch mal in Richtung einem Software Design Buch ;-)

C# ist Sprache, die durchaus für Enterprise und profesionellen Einsatz gedacht ist.
Daher ist sie natürlich entsprechend flexibel - was aber die Gefahr birgt gewisse Dinge falsch einzusetzen; wie nun hier.
Neuer Beitrag 30.01.2019 10:34 Beiträge des Benutzers | zu Buddylist hinzufügen
T-Virus T-Virus ist männlich
myCSharp.de-Mitglied

Dabei seit: 17.04.2008
Beiträge: 1.367
Entwicklungsumgebung: Visual Studio, Codeblocks, Edi
Herkunft: Nordhausen, Nörten-Hardenberg


T-Virus ist offline Füge T-Virus Deiner Kontaktliste hinzu

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

@trashkid2000
ThomasE. und Abts Aussagen halte ich hier schon für richtig und gewichtet.
Gerade wenn du dich beim Thema API Design und auch generell mit Software Architekturen befasst, wirst du schnell merken, dass solche Lösung alles andere als sauber und sogar bei falscher Anwendung auch Gefahren bergen.

Mal von den grundsätzlichen Vertoß gegen saubere OOP abgesehen, kannst du dir mit solchen Winkellösungen schnell ins Knie schießen.
Zusätzlich zu dem Mehraufwand auf deiner Seite um solch einen De-/Serialisierer umzusetzen bekommst du auch Probleme wenn du dann entscheiden musst welche privaten Felder nun serialisiert werden dürfen und welche nicht.

Genau dies kann man bei Eigenschaften schon durch normales Klassen Design mit öffentlichen und privaten Eigenschaften lösen ohne Sonderlösungen zu benötigen.
Und genau auf solche simplen Designentscheidungen achten alle gängigen De-/Serialisierer.
Hier reden wir schon von Grundsätzen die man hier einfach erwarten muss.

Es ist dir natürlich überlassen solche Lösungen umzusetzen.
Aber gerade als Entwickler der täglich mit unterschiedlichen APIs und auch Software Architekturen samt deren Umsetzungen/Anpassung zu tun hat, würde ich einen großen Bogen um solche Lösungen machen.

Das kann man nach mehr als 10 Jahren Erfahrung dann nicht mehr guten Gewissens machen.
Dafür gibt es einfach saubere und vorallem durchdachte Lösungen.
Hier wieder das Rad neu zu erfinden um es wieder einmal runder zu machen zeugt meistens von mangelhafter Erfahrung was generelle und grundsätzliche Lösungswege angeht.

T-Virus
Neuer Beitrag 30.01.2019 19:54 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
trashkid2000 trashkid2000 ist männlich
myCSharp.de-Mitglied

Dabei seit: 27.12.2010
Beiträge: 156


trashkid2000 ist offline

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

Zitat von T-Virus:
Hier wieder das Rad neu zu erfinden um es wieder einmal runder zu machen zeugt meistens von mangelhafter Erfahrung was generelle und grundsätzliche Lösungswege angeht

natürlich Daumen hoch

Und nein, nach mehr als 10 Jahren damit vertraut keine mangelnde Erfahrung...
Vielleicht nur manchmal einfach (zu sehr) auf Sicherheit bedacht Augenzwinkern
Neuer Beitrag 30.01.2019 22:03 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 10 Monate.
Der letzte Beitrag ist älter als 10 Monate.
Antwort erstellen


© Copyright 2003-2019 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 16.12.2019 08:21