Properties einer Klasse von aussen setzen und via String adressieren

Hallo,

ich habe mal wieder eine Anfängerfrage.
Es geht darum, wie ich am effektivsten einen String in die Eigenschaften einer Klasse überführt bekomme.
Meine derzeitige Lösung sieht ungefähr so aus:

    public class Class1
    {
        public double Key1 { get; set; }
        public double Key2 { get; set; }
        public double Key3 { get; set; }

    }

    public class Class2
    {
        public Class1 Convert()
        {
            string stringToConvert = "Key1 Value1, Key2 Value2, Key3 Value3";

            string[] pairs = stringToConvert.Split(',');
            Class1 class1 = new Class1();

            foreach (string pair in pairs)
            {
                string[] values = pair.Split(new char[] { ' ' }, StringSplitOptions.RemoveEmptyEntries);
                double value = double.Parse(values[1]);
                if(values[0].Equals("Key1"))
                {
                    class1.Key1 = value;
                }
                else if (values[0].Equals("Key2"))
                {
                    class1.Key2 = value;
                }
                else if (values[0].Equals("Key3"))
                {
                    class1.Key3 = value;
                }
            }
            return class1;
        }
    }

Meine Frage zielt auf die if-Abfragen ab. Gibt es da einfachere Möglichkeiten, eine Verbindung zwischen Key<x> des Strings und Key<x> der Eigenschaft von Class1 herzustellen?

Hallo Caveman,

mal insgesamt gefragt: Was hast du denn vor?

Gruss

Coffeebean

Hallo,
es geht darum, dass ich eine Textdatei parsen, und die verschiedenen enthaltenen Datenformate in Klassen darstellen möchte.
Die Klassen habe ich bereits erstellt. Die Schwierigkeit ist nun, den String in die Klasse zu überführen.
In dem Beispiel habe ich nur drei Paare dargestellt. Es können aber auch sechzehn Paare sein. Dann wird es schon lästig, mit if-Abfragen zu arbeiten.
Der einfachste Weg mit

class1.value[0] = value

funktioniert leider nicht!

In dem Fall könnte sich Reflection anbieten. Stichwort: PropertyInfo.SetValue

Falls der Name (im String) nicht 1:1 dem Eigenschaftsnamen entspricht, könntest du auch noch eine Mapping-Tabelle benutzen.

Falls es in Frage kommt könntest Du alternativ auch über den Einsatz eines Dictionarys nachdenken.

Dictionary<string, double> values = new Dictionary<string, double>();

Danke, das mit Reflection werde ich heute Abend nach der Arbeit mal ausprobieren.
Dictionaries hatte ich auch schon probiert. Diese helfen mir aber für zukünfige Aufgaben nicht weiter - denke ich zumindest aktuell!

Hallo, so wie es aussieht, willst du ein Mapping zwischen einer ?Konfigurationsdatei und einer Klasse herstellen?

Was ist das für eine Textdatei? Von wo kommt sie?

Hi,

also um ehrlich zu sein - deinen Ansatz mit der Klasse kann ich nicht nachvollziehen - oder hast du später allen Ernstes vor eine Klasse mit 16 (und mehr?) Properties zu schreiben?

Was spricht denn später gegen die einfache Verwendung von Dictionary<string, double>?

Alternativ kannst du dir auch mal https://weblog.west-wind.com/posts/2012/Feb/08/Creating-a-dynamic-extensible-C-Expando-Object anschauen - da wird das mit einem ExpandoObject gelöst, sodass es sich zumindest so anfühlt als ob.

LG

Nun ja, vielleicht soll ich doch noch etwas mehr erzählen!
Nach mehreren Jahren der mühevollen Einarbeitung in C#, Objektorientierung, Frameworkdesign usw. habe ich für mich erneut entschieden, ein kleines Framework für Industrieroboter zu programmieren. Für den Anfang sollen die Roboter von Kuka, ABB und Fanuc realisiert werden.
Die Daten kommen aus den Roboterbackups.
Das erste Ziel sollte sein, aus den Backups ein Robotermodell zu bauen.
Das kann dann wiederum verwendet werden, um verschiedene Parameter zu dokumentieren.
Außerdem will ich zu einem späteren Zeitpunkt noch versuchen, Programme von einer Steuerung auf eine andere Steuerung zu transformieren.
Ob mir das alles gelingt weiß ich nicht. Es ist aber nicht mein erster Versuch in dem Thema X(

Dictionaries hatte ich auch schon probiert. Diese helfen mir aber für zukünfige Aufgaben nicht weiter - denke ich zumindest aktuell!

Beschreib uns doch mal kurz die zukünftigen Aufgaben, bzw. wie Du geplant hattest die im Eingangsbeitrag genannte Klasse zukünftig zu verwenden.

In dem Fall könnte sich Reflection anbieten. Stichwort: PropertyInfo.SetValue

Falls der Name (im String) nicht 1:1 dem Eigenschaftsnamen entspricht, könntest du auch noch eine Mapping-Tabelle benutzen.

Ich habe mich jetzt in das Thema Reflection etwas eingelesen und es ist genau das, was ich gesucht habe.
Vielen Dank nochmals Th69 für den Tipp!

Reflection ist zu 99% die falsche Lösung.

Beschreibe lieber mal was du erreichen möchtest, nicht wie du meinst es lösen zu müssen.

Reflection ist zu 99% die falsche Lösung.

Beschreibe lieber mal was du erreichen möchtest, ...

Ist das aus dem Eingangspost nicht ersichtlich?
Wenn nein, welche Infos fehlen denn dann noch?
Und warum soll Reflection nun schon wieder der falsche Weg sein?

Es gibt in 99% der Fälle einen besseren Weg als Reflection.
Ich hab aber auch noch nicht verstanden, was er wirklich tun will.

Hi,

warum machst Du nicht statt

 public double Key1 { get; set; }

public double[] Key { get; set; }
public int KeyCount { get { return Key.Length; } }

?

dann brauchst du nicht Key1 bis Key16 mehrfach programmieren.

Diese Verteufelung von Reflection kann ich ehrlich gesagt nicht nachvollziehen.
Jede CSV-Library arbeitet mit Reflection, zumindest sobald sie die Daten auch gegen eine Klasse mappt.
Das gleiche gilt für jede XML-Library (und JSON), jedes ORM, etc.
Sobald irgendwelche Werte anhand von String-Keys gegen ein Objekt gemapped werden sollen, ist Reflection im Spiel und das aus gutem Grund.

Ich tippe mal darauf, dass Caveman irgendein Datenformat hat, was keinem gängigen Format wie CSV oder XML folgt, ein vorhandenes Framework kann er also nicht verwenden.
Dieses Format will also gelesen werden und die Daten sollen am Besten in einer Klasse mit Properties landen.
Im schlimmsten Fall gibt es sogar viele verschiedene Dateien, die zwar dem selben Format folgen, aber unterschiedliche Keys haben.
Wir wissen ja auch nicht, ob das gezeigte Beispiel wirklich das echte Format ist, das kann ja noch weit komplexer sein.

Ich persönlich würde in so einem Fall - wenn ich wirklich viele verschiedene Dateien mit dem gleichen Format habe - ein kleines Mini-Framework bauen, was anhand eines einfachen Mappings (Key zu Property) die Inhalte lesen kann. Oder ein automatisches Mapping anhand der Property-Namen (oder ein KeyNameAttribute), was viel Schreibarbeit spart.
Das mag dann zwar komplett auf Reflection aufbauen, dafür ist der Code überschaubar, flexibel wiederverwendbar und der Aufrufer bekommt das denkbar einfachste Ergebnis zurück: Ein Objekt der gemappten Klasse mit typisierten Properties, wie er sie braucht.

Klar kann man auch ohne Reflection arbeiten.
Aber ist das wirklich besser, oder einfach nur eine eingefleischte Abneigung gegen Reflection?

PS:
Aber ich gebe zu, wenn es nur eine Liste von Werten des selben Typs (z.B. Double) ist, dann tuts auch ein Dictionary.
Wobei ich da aber trotzdem gegen eine Klasse mappen und via Reflection schreiben würde, weil dann 1. Änderungen an den Keys in der Datei früh (nämlich beim Lesen) auffallen und 2. überall die IntelliSense hilft.

Ich wollte schon gestern fragen, wie so eine Datei aussieht und ob er eine Beispiel-Datei anhängen kann, dann sieht man sofort wo der Hase hinläuft...

Es geht ja im Prinzip vorerst darum, so eine Daten/Informationsdatei eines z.Bsp. ABB Roboter Backups in eine Klasse zu transferieren, wie ich es verstanden hatte.

Was er danach mit den Daten macht ist eigentlich egal, denn das war, schätze ich, seine Frage.
Andere Fragen kommen dann so oder so wieder in ein neues Thema, schätze ich... :evil:

@Palladin007:
Das hat nichts mit verteufeln zu tun, denn die von Dir angesprochenen Bereiche machen doch gerade mal 1% aus.

Wer schreibt denn ständig seinen ORMapper selber/Neu oder seinen Serialiser?

Das tut vermutlich niemand 😄

Was ich eher sagen wollte, ist, dass wir durchaus davon ausgehen sollten, dass dieser konkrete Fall einer dieser Fälle ist, wo Reflection Sinn macht.

Diese Verteufelung von Reflection kann ich ehrlich gesagt nicht nachvollziehen.
Jede CSV-Library arbeitet mit Reflection, zumindest sobald sie die Daten auch gegen eine Klasse mappt.
Das gleiche gilt für jede XML-Library (und JSON), jedes ORM, etc.
Sobald irgendwelche Werte anhand von String-Keys gegen ein Objekt gemapped werden sollen, ist Reflection im Spiel und das aus gutem Grund.

Es ist leider nicht nur mit Reflection so. Gleiches gilt z.B. auch beim Thema Schnittstellen. Der eine sagt, man soll auf Schnittstellen programmieren, der andere sagt nein. Hab mir auch das Buch "Framework Design Guidelines" für mein Vorhaben zugelegt. Da wird im Übrigen auch von Programmierung auf Schnittstellen abgeraten. Aber keiner sagt WARUM!
Und das ist auch für mich eines der größten Probleme hier in diesem Forum. Viele hier haben anscheinend keine Ahnung, mit was für Problemen wir Programmieramateure uns rumschlagen müssen. Was soll ich davon halten, wenn zig verschiedene Meinungen zu einem simplen Problem vorgetragen werden? Ich weiß jetzt z.B. immer noch nicht, warum Reflection zu 99% falsch sein soll!

Ich tippe mal darauf, dass Caveman irgendein Datenformat hat, was keinem gängigen Format wie CSV oder XML folgt, ein vorhandenes Framework kann er also nicht verwenden.
Dieses Format will also gelesen werden und die Daten sollen am Besten in einer Klasse mit Properties landen.
Im schlimmsten Fall gibt es sogar viele verschiedene Dateien, die zwar dem selben Format folgen, aber unterschiedliche Keys haben.
Wir wissen ja auch nicht, ob das gezeigte Beispiel wirklich das echte Format ist, das kann ja noch weit komplexer sein.

Genau so ist es! Vielen Dank für Deine Worte!

Ich persönlich würde in so einem Fall - wenn ich wirklich viele verschiedene Dateien mit dem gleichen Format habe - ein kleines Mini-Framework bauen, was anhand eines einfachen Mappings (Key zu Property) die Inhalte lesen kann. Oder ein automatisches Mapping anhand der Property-Namen (oder ein KeyNameAttribute), was viel Schreibarbeit spart.
Das mag dann zwar komplett auf Reflection aufbauen, dafür ist der Code überschaubar, flexibel wiederverwendbar und der Aufrufer bekommt das denkbar einfachste Ergebnis zurück: Ein Objekt der gemappten Klasse mit typisierten Properties, wie er sie braucht.

Genau das ist mein Vorhaben! Und es ist mittlerweile auch schon mein vierter Versuch X(

Ich wollte schon gestern fragen, wie so eine Datei aussieht und ob er eine Beispiel-Datei anhängen kann, dann sieht man sofort wo der Hase hinläuft...

Ich habe mal eine konkrete Datei angehängt. Die Endung ist .dat

Und wenn dir ein "Lehrbuch" pauschal von Interfaces abrät, solltest du das ganz weit wegwerfen.
Interfaces sind die einzig sinnvolle Art grössere Software zu designen, da man nur dann z.b. für UnitTests einige Teile austauschen kann.
Wie willst du z.b. Businesslogik vernünftig testen, wenn du nur festverdrahtete Datenbanken drunter hast?

Viele hier haben anscheinend keine Ahnung, mit was für Problemen wir Programmieramateure uns rumschlagen müssen

Deswegen fragte ich ja nach dem Problem, und nicht nach deinem Lösungsversuch.

Und wenn dir ein "Lehrbuch" pauschal von Interfaces abrät, solltest du das ganz weit wegwerfen.

Nicht pauschal!
Das "Lehrbuch" ist übrigens von B. Abrams und K. Cwalina

Aber bitte zurück zum Thema. Wir sind schon ganz weit Offtopic!

Ich denke, das größte Problem ist, dass Reflection "zu" dynamisch ist.
Damit kann man zwar irre viel machen, aber auch irre viel falsch machen, weil beinahe alles möglich ist. Du kannst ja sogar readonly-Variablen verändern - nur mal als Gedankenanstoß 😉
Wo das hin führt, sieht man ja bei Sprachen wie PHP, Pearl, JavaScript, etc. (nichts gegen Entwickler aus dem Bereich). Die sind alle sehr flexibel (schwach typisiert), was viele Möglichkeiten und Freiheiten bietet, was aber schnell zu einer Schwäche werden kann.

Ein Beispiel, wo Reflection durchaus wichtig ist, aber auch zu Problemen führen kann: Jeder x-beliebige XML-Parser
Entwickler A baut irgendeine Klasse mit irgendwelchen Properties
Entwickler B will ein solches Objekt als XML lesen/schreiben. Er nutzt dafür den XmlSerializer, der sich automatisch sein Schema per Reflection aus der Klasse zusammen baut.
Nun ändert Entwickler A eine Property (Name, what ever), weiß dabei aber nichts davon, dass da Serialisierung dran hängt.
Und das Ende vom Lied: Irgendwo in der Anwendung knallt es, weil irgendeine Property nicht den richtigen Wert hat, weil der XmlSerializer das Gegenstück in der XML nicht finden kann.
Oder noch schlimmer: Das Objekt wird mit dem unbemerkt verändertem Format geändert, zu Mitarbeiter XY weiter gegeben und der beschwert sich dann bei Mitarbeiter Z, dass sein Programm an irgendeiner Stelle knallt.
Am Ende sind alle verwirrt, weil doch niemand die Serialisierung angefasst hat.
Viel einfacher wäre es doch, wenn Entwickler A gar nicht erst compilen kann, weil der Compiler die andere Property nicht mehr kennt, oder nicht? 😉

Ich gebe zu, das Beispiel ist nicht besonders gut, weil in dem Fall an anderen Stellen schon einiges schief gelaufen sein muss.
Aber es ist (denke ich) nachvollziehbar.
Interessanter ist dagegen eine Sonder-Lösung, die irre komplexe Sachen auf Basis von Reflection macht.
Es passiert zu schnell, dass irgendwer auf irgendwas achten muss, wovon er gar nichts wissen kann/sollte, weil das über Umwege via Reflection passiert.
Oder in kurz: Reflection wird sehr schnell sehr intransparent und komplex.

Was deine Datei angeht: Das sieht ziemlich komplex aus 😄
Auf den zweiten Blick (so ab Hälfte) sieht das wie eine Art Script aus, sehe ich das richtig?
Dann würde ich auch in diese Richtung entwickeln.
Jede Zeile ist eine Anweisung. Wenn sie mit DECL beginnt, bedeutet es, dass eine Variable deklariert wird.
Alle Anweisungen mit einem Gleichzeichen sind Variablen-Zuweisungen.

Ganz ganz "einfach" gedacht:
Du hast einen Kontext mit einen Dictionary<string, VariableEntry> für die Variablen-Werte
Dieser Kontext hat viele Operationen, wie CreateVariable() und GetVariable()
Dazu gibts ein Interface IOperation mit einer Methode Execute(Kontext)
Und an dritter Stelle brauchst Du ein System, was den String parsed und anhand dessen bestimmt, welche der Operationen das ist, das Objekt dazu erstellt und mit den Inhalten der Zeile füttert.
Anschließend hast Du eine Liste von Operationen, die Du nacheinander auf den selben Kontext ausführst.
DANACH hast Du ein Kontext-Objekt mit Werten, aus denen Du dann ein Ergebnis-Objekt bauen kannst.

Bei so einer oder so ähnlichen Herangehensweise kommst Du die meiste Zeit ohne Reflection aus, der Teil, der tatsächlich mit Reflection arbeitet hat eine sehr einfach und klar definierte Aufgabe: Schreibe Variablen-Wert vom Kontext in Property von Objekt.
Zumindest, wenn ich nicht völlig daneben liege 😄

PS:
Wie es scheint, gibt's da auch Deklaration von neuen Typen?
Eigener Enum-Typ und ein Typ mit mehreren möglichen Inhalten
Das musst Du dann auch entsprechend mit schreiben, welcher Typ da deklariert wurde und wie der heißt, wie der aussieht, etc.

Das "Lehrbuch" ist übrigens von B. Abrams und K. Cwalina

Du zitierst nun nicht wirklich ein Lehrbuch von >2001< - oder?

Du zitierst nun nicht wirklich ein Lehrbuch von >2001< - oder?

Nein, aus 2009!

... bei Sprachen wie PHP, Pearl, JavaScript, etc. (nichts gegen Entwickler aus dem Bereich). ...

Du meinst sicher Perl - Practical Extraction and Reporting Language. Das ist eine der coolsten Sprachen überhaupt!

... Aber es ist (denke ich) nachvollziehbar. ...

Ja, ist nachvollziehbar. Aber ausser mir wird da nie jemand anders Hand anlegen! Und für mich geht es in allererster Linie um den Lerneffekt.

... Auf den zweiten Blick (so ab Hälfte) sieht das wie eine Art Script aus, sehe ich das richtig?...

Nein, das ist eine reine Konfigurationsdatei. Mich interessiert aber nicht alles, was in der Datei steht.

Ganz ganz "einfach" gedacht:
Du hast einen Kontext mit einen Dictionary<string, VariableEntry> für die Variablen-Werte
Dieser Kontext hat viele Operationen, wie CreateVariable() und GetVariable()
Dazu gibts ein Interface IOperation mit einer Methode Execute(Kontext)
Und an dritter Stelle brauchst Du ein System, was den String parsed und anhand dessen bestimmt, welche der Operationen das ist, das Objekt dazu erstellt und mit den Inhalten der Zeile füttert.
Anschließend hast Du eine Liste von Operationen, die Du nacheinander auf den selben Kontext ausführst.
DANACH hast Du ein Kontext-Objekt mit Werten, aus denen Du dann ein Ergebnis-Objekt bauen kannst.
Bei so einer oder so ähnlichen Herangehensweise kommst Du die meiste Zeit ohne Reflection aus, der Teil, der tatsächlich mit Reflection arbeitet hat eine sehr einfach und klar definierte Aufgabe: Schreibe Variablen-Wert vom Kontext in Property von Objekt.
Zumindest, wenn ich nicht völlig daneben liege 😄

Hier wirft mein Betriebssystem eine FailedToUnderstandException 😉

Ich werde das jetzt mit Reflection weiter verfolgen. Scheint mir am einfachsten zu sein.
Als Ergänzung hier noch meine definierten Klassen. Im Summary steht dann, was da rein soll.

    public class KukaTool
    {
         /// <summary>
        /// Index von TOOL_DATA, TOOL_NAME oder TOOL_TYPE
        /// </summary>
        public int Number { get; set; }

        /// <summary>
        /// Der Name von TOOL_NAME[1,]="Toolname 1"
        /// </summary>
        public string Name { get; set; }

        /// <summary>
        /// TOOL_DATA[1]={X 0.0,Y 15.0000,Z 404.000,A 0.0,B 0.0,C 0.0}
        /// </summary>
        public KukaFrame Location { get; set; }

        /// <summary>
        /// Der Typ von TOOL_TYPE[1]=#BASE
        /// </summary>
        public Enums.KukaFrameType Type { get; set; }
    }

    public class KukaFrame
    {
        public double X { get; set; }

        public double Y { get; set; }

        public double Z { get; set; }

        public double A { get; set; }

        public double B { get; set; }

        public double C { get; set; }
    }

Du meinst sicher Perl - Practical Extraction and Reporting Language. Das ist eine der coolsten Sprachen überhaupt!

Lass mich raten: Das war eine der Sprachen, mit denen Du angefangen hast?
Sonst hab ich diese Aussage noch nie gehört 😄

Ich musste ein halbes Jahr mit Pearl arbeiten.
Ich gebe zu: Es hat irgendwie Spaß gemacht
Aber auch nur, weil es heilloses Gefrickel war 😄

Ja, ist nachvollziehbar. Aber ausser mir wird da nie jemand anders Hand anlegen! Und für mich geht es in allererster Linie um den Lerneffekt.

Du darfst aber auch nicht vergessen, dass Du in einigen Monaten oder Jahren im Extremfall genauso wenig über deine Anwendung weißt, wie ein potentieller Kollege, der sie noch nie gesehen hat 😛
Man sollte denke ich immer davon ausgehen, dass die Anwendung auch von jemand Anderem überarbeitet werden muss, einfach weil es hilft, den Code so zu schreiben, dass der (Wieder-) Einstieg später leichter ist.

Nein, das ist eine reine Konfigurationsdatei. Mich interessiert aber nicht alles, was in der Datei steht.

Soweit hab ich das verstanden, aber wie ist sie aufgebaut?
Beispiel:

DECL FRAME TOOL_DATA[16]
TOOL_DATA[1]={X 0.0,Y 15.0000,Z 404.000,A 0.0,B 0.0,C 0.0}
TOOL_DATA[2]={X 0.0,Y 15.0000,Z 404.000,A 0.0,B 0.0,C 0.0}
TOOL_DATA[3]={X 0.0,Y 0.0,Z 404.000,A 0.0,B 0.0,C 0.0}
TOOL_DATA[4]={X 0.0,Y 0.0,Z 404.000,A 0.0,B 0.0,C 0.0}
TOOL_DATA[5]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
TOOL_DATA[6]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
TOOL_DATA[7]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
TOOL_DATA[8]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
TOOL_DATA[9]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
TOOL_DATA[10]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
TOOL_DATA[11]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
TOOL_DATA[12]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
TOOL_DATA[13]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
TOOL_DATA[14]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
TOOL_DATA[15]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
TOOL_DATA[16]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}

Das sieht für mich wie eine Array-Zuweisung aus.
Die Erste Zeile scheint die Deklaration mit Typ, Name und Größe des Arrays zu sein.
Alle Zeilen danach sind dann die einzelnen Wert-Zuweisungen.

Da hast Du nun die Wahl:
Willst Du 16 Properties mit hoch gezähltem Namen haben, oder
Willst Du eine Property mit Array haben?
Ich würde zu Letzterem tendieren.

Spätestens bei so einem Fall reicht das einfache Name=Wert-Mapping Zeile für Zeile nicht mehr aus, denn Du brauchst auch Informationen, die irgendwo weiter vorne in der Datei stehen.
Dazu kommt noch, dass jede Zeile mehrere Werte enthält, die wiederum in einem eigenen Objekt mit den float-Properties X, Y, A, B und C landen sollen, richtig?

Allerdings: Wenn Du diese Daten gar nicht brauchst, musst Du sie auch nicht raus lesen.
Wenn Du später aber fest stellst, dass Du sie doch brauchst, dann hast Du Spaß, das zu ergänzen, oder alles umzubauen 😉

Ich musste ein halbes Jahr mit Pearl arbeiten.
Ich gebe zu: Es hat irgendwie Spaß gemacht
Aber auch nur, weil es heilloses Gefrickel war 😄

Jetzt schreibst Du schon wieder Pearl! 🤔
Meinst Du jetzt Perl - Die Sprache mit dem Kamellogo, die Larry Wall erfunden hat, oder PEARL (Process and experiment automation realtime language))

Du darfst aber auch nicht vergessen, dass Du in einigen Monaten oder Jahren im Extremfall genauso wenig über deine Anwendung weißt, wie ein potentieller Kollege, der sie noch nie gesehen hat 😜
Man sollte denke ich immer davon ausgehen, dass die Anwendung auch von jemand Anderem überarbeitet werden muss, einfach weil es hilft, den Code so zu schreiben, dass der (Wieder-) Einstieg später leichter ist.

Ich bin und bleibe der Einzige, der daran rumfingert. In meinem Umfeld kenne ich niemanden, der sich auch nur annähernd fürs programmieren interessiert. Deshalb bleiben mir auch nur Bücher, Foren und Google. Die Lernkurve ist demzufolge auch relativ flach!
Da ich mich bereits im fortgeschrittenen Alter befinde, weiß ich das sehr häufig schon zwei Wochen später gar nicht mehr! 😁

Da hast Du nun die Wahl:
Willst Du 16 Properties mit hoch gezähltem Namen haben, oder
Willst Du eine Property mit Array haben?
Ich würde zu Letzterem tendieren.

Man soll ja mit Komposition arbeiten. Deshalb gibt es im Roboterobjekt eine Eigenschaft

public override List<KukaTool> Tools { get; set; }

Allerdings: Wenn Du diese Daten gar nicht brauchst, musst Du sie auch nicht raus lesen.
Wenn Du später aber fest stellst, dass Du sie doch brauchst, dann hast Du Spaß, das zu ergänzen, oder alles umzubauen 😉

Ja, dessen bin ich mir bewußt. Aber Strafe muß sein und Übung macht den Meister.

Ach verdammt, den Hinweis auf den Schreibfehler hab ich ganz übersehen 😄
Ich meine natürlich Perl 😄

Da ich mich bereits im fortgeschrittenen Alter befinde, weiß ich das sehr häufig schon zwei Wochen später gar nicht mehr! großes Grinsen

Ein Grund mehr, darauf zu achten, dass Du dir keine Fallstricke einbaust 😛

Man soll ja mit Komposition arbeiten. Deshalb gibt es im Roboterobjekt eine Eigenschaft

public override List<KukaTool> Tools { get; set; }  

Stimmt, so kann man's auch machen.
Mein Konzept zielte auch darauf ab, die ganze Datei zu lesen und vielleicht auch zu validieren oder - falls es notwendig werden sollte - auch zu schreiben.

Was für dich der beste Weg ist, musst Du entscheiden.
Wenn es ein privates Projekt ist, hast Du natürlich auch den Vorteil, dass Du deine Zeit selber einteilen und bei Bedarf auch mal alles über den Haufen werden kannst, ohne dass es jemanden Stört.
Das gibt viel Freiraum, auch mal was auszuprobieren.

Das sind Konfigurationsdateien für einen Mehrachsigen KUKA-Roboterarm; es würde jedenfalls exakt zu dem passen, was ich schon mal damit gemacht habe.
Das wird also vermutlich kein privates Projekt sein.

Wir haben für solche Dinge immer ServiceStack.Text verwenden.
Lernen schön und gut; aber gerade bei sowas evtl. lieber auf was bewährtes setzen.