Laden...

Klasse für Txt in Dictionary wahlweise <int, int> oder <string, int>

Erstellt von Mackerlama vor 13 Jahren Letzter Beitrag vor 13 Jahren 1.595 Views
M
Mackerlama Themenstarter:in
118 Beiträge seit 2008
vor 13 Jahren
Klasse für Txt in Dictionary wahlweise <int, int> oder <string, int>

Hallo,

ich möchte mich nun mal an etwas härtere Kost heran wagen (zu mindest für mich).

Da ich aktuell diverse Textdateien (die Datensätze in Zeilenform enthalten) verarbeite und in Dictionarys <int, int> oder <string, int> packe, um dann weitere Arbeitsschritte zu machen, dachte ich mir, dass eine eigene Klasse dafür angebracht wäre. Bisher habe ich immer für jeden Vorgang quasi eine eigene Klasse gemacht und dann komplett prozedural gearbeitet. Nun will ich aber mal OOP lernen bzw. Best Practise.

Die Klasse soll flexibel sein. Es soll möglich sein eine einzelne Textdatei zu verarbeiten, aber auch ein ganzes Verzeichnis. Dazu soll natürlich noch gesetzt werden können, welcher Index pro Textzeile überhaupt relevant ist. Am Ende soll jedenfalls das Dictionary zurückgegeben werden bzw. eine Referenz. (ich hoffe die Formulierung ist korrekt)

Mein aktuelles Problem ist, dass ich je nach Verarbeitung ein Dictionary<int, int> oder Dictionary<string, int> brauche. Wie kann ich das in der Klasse am besten realisieren? Wirklich Zwei Dictionary definieren und dann Zwei getrennte Füll-Methoden? Oder geht das Eleganter?

LG, Realnub

125 Beiträge seit 2008
vor 13 Jahren

Dictionary<NewClass,int>

Die NewClass klasse mit 2 Konstruktoren für int und string?

M
Mackerlama Themenstarter:in
118 Beiträge seit 2008
vor 13 Jahren

Hallo gnc,

danke für deine Antwort.

Ich weiß nicht, ob ich dich richtig verstehe. Du willst, dass ich eine Hilfsklasse verwende?

125 Beiträge seit 2008
vor 13 Jahren

Jap!
Ich weiß auch nicht ob ich dich richtig verstanden habe 😄

J
3.331 Beiträge seit 2006
vor 13 Jahren

Hallo,

wenn du dich mit OOP beschäftigen willst (und das ist immer wichtig und richtig, erst recht mit .NET), dann musst du auch "richtig denken": Eine Klasse soll ein Objekt der Wirklichkeit abbilden. Also solltest du zuerst darüber nachdenken, welchen Teil der Wirklichkeit du behandeln willst: eine Datei oder eine Textzeile oder nicht eher einen bestimmten Sachverhalt oder...

Dann geht es weiter: Welche Eigenschaften haben diese Objekte? Welche Aktionen können diese Objekte vornehmen, welche Aktionen macht ein Benutzer damit?

Auf diese Weise kommst du sozusagen zwangsläufig zu einer Klassenstruktur.

Ich kann keinen Sinn darin erkennen, eine Textdatei als eigene Klasse zu definieren. Es wird schon (je nach Programmsituation) von .NET als Stream, als Folge von Zeilen oder als String-Array zur Verfügung gestellt. Damit kann alles erledigt werden, was denkbar ist. Eine eigene Klasse ist doch nur dann sinnvoll, wenn der Inhalt der Textdatei einen besonderen Teil der Wirklichkeit beschreibt.

Gruß Jürgen

M
Mackerlama Themenstarter:in
118 Beiträge seit 2008
vor 13 Jahren

Ich will doch keine Textdatei als Klasse. Ich will nur eine Klasse, die mir den Inhalt der Textdatei (reduziert) in ein Dictionary packt.

Die Datensätze in der Textdatei haben >10 Felder. Ich verwende aber für meine Auswertungen nur 2 oder 3 davon. Mal ist der Key ein Int und mal ist der Key ein zusammengesetzter string.

Bisher habe ich halt Copy & Paste von dem "Einlese"-Code gemacht. Eine eigene Klasse wäre doch sauberer, als reduntanter Code.

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Realnub,

ja, wobei du gedanklich anscheinend immer noch bei dem Versuch bist, deinen prozeduralen Code bloß irgendwie durch eine Klasse zu kapseln. Da du aber anderseits sagst, dass du OOP lernen willst, solltest du dich schon auf das einlassen, was juetho sagt. Tritt mal ganz von deiner bisherigen Lösung zurück und überlege dir von Anfang an neu, was die Klasse überhaupt repräsentieren soll. Erst in einem zweiten und separaten Schritt geht es dann um die Implementierung.

herbivore

M
Mackerlama Themenstarter:in
118 Beiträge seit 2008
vor 13 Jahren

Ja scheinbar steige ich noch nicht bei euren Aussagen durch.

Aber eine andere Frage:

Wieso geht das nicht?

private dictionary<tkey, tvalue> masterData;
private string valueType;

// Konstruktoren, Methoden usw.
// valueType wurde mittlerweile initialisiert, z.b so
valueType = "System.Int32";

// nun die Fehler
// 1) GetType ist eine MEthode, wird aber wie ein Typ verwendet
// 2) Überladene Methode "..." üngültige Argumente
masterData = new dictionary<int, System.Type.GetType(valueType)>();

Oder geht das generell nicht?

//------------------------------------------------------------------------------------

Zum Thema OOP. Eine Klasse oder Assembly erstellen um eine wiederkehrende Aufgabe zu erledigen hat mit OOP nur bedingt etwas zu tun. Das ist richtig. Könnte genauso gut auch eine Prozedur sein.
Ich dachte halt, dass ich die Aufgabe seperat anlege und so immer wieder verwenden kann.

Mir fällt es schwer meine Aufgaben OOP verpackt zu sehen bzw. zu erstellen.
Könnte mein Wunsch vielleicht so aussehen, dass ich 2 Klassen und einInterface erstelle. Die Klassen implementieren das Interface und über das greife ich später zu? (eine Klasse für int und eine für string)

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Realnub,

Oder geht das generell nicht?

richtig, Typparameter von generischen Klassen müssen immer zu Compilzeit bekannt sein und explizit angegeben werden.

Könnte mein Wunsch vielleicht so aussehen, dass ich 3 Klassen erstelle. Eine als abstracte Basisklasse und 2 weitere die diese beereben und den Typ ergänzen?

Das ist schon zu technisch gedacht. Überleg dir doch mal inhaltlich, was für Klassen du brauchst. Ein Indiz dafür, dass du auf dem richtigen Weg bist, ist, wenn du der Klasse einen kurzen, knackigen, sprechenden Namen geben kannst (echtes Substantiv, keine substantiviertes Verb).

herbivore

M
Mackerlama Themenstarter:in
118 Beiträge seit 2008
vor 13 Jahren

Ok, also danke für eure Hilfe.

Vermutlich ist es besser, ich schaue mir noch mal die Basics an und gehe, dann so vor, wie ihr mir das empfiehlt. Wird also etwas dauern, bis ich mich wieder zu Wort melde.