Zum Inhalt springen

Rangliste

Beliebte Inhalte

Inhalte mit der höchsten Reputation am 05.01.2017 in allen Bereichen anzeigen

  1. Ne eben nicht, es gibt einen Rahmenplan für Betriebe in allen Bereichen, und da muss sich jeder Betrieb halten. Die IHK ist ja im Prinzip auch gleichzeitig eine Aufsichtsbehörde für solche Sachen. Und wenn die Betriebe dem Rahmenplan nicht folgen, dürft ihr den Betrieb wechseln bzw die IHK hilft euch dabei. Gruß Sent from my iPhone using Fachinformatiker.de mobile app
    2 Punkte
  2. Sehr geehrte Damen und Herren, ich und meine Mit-Azubis haben Probleme in unserem Ausbildungsbetrieb. Schilderung der Lage: Wir, vier Azubis, [edit, C.W.] Auszubildende Fachinformatiker für Systemintegration, bewarben uns auf eine Stelle welche mit "Netzwerke, Server, globale IT Infrastruktur" beworben wurde. Seit Tag Eins gab es ein durchgehendes Durcheinander in der Firma(bzw. explizit an unserem Standort). Unsere Firma ist dezentralisiert in Deutschland. Auswahlverfahren und Verwaltung sind an einem anderen Standort als der Ausbildungsstandort. Am ersten Tag wusste keiner Bescheid an unserem Standort, dass vier Auszubildende kommen. Wir sind wohl der erste Jahrgang für diesen Standort nach Übernahme einer anderen Firma. Unser Ausbilder, welcher auf dem Vertrag vermerkt ist, wusste nicht, dass wir kommen und hatte zu dem Zeitpunkt auch noch Urlaub. Das Ganze zog sich jetzt durch. Niemand mag sich so recht mit uns zu befassen, keiner fühlt sich verantwortlich und unser "Ausbilder" darf nicht handeln oder uns ausbilden, weil die Personalverwaltung das wohl so will. Wir haben unsere entsprechende verantwortliche Person für die Azubis in Deutschland darauf angesprochen, dass das so nicht geht. Stattdessen wurden wir abgespeist mit der Antwort, dass es nun mal so geregelt ist in der Firma. Dazu kommt, dass unser Standort fast ausschließlich Telefonanlagen verwaltet, konfiguriert, einrichtet, im Gegenteil zur Stellenausschreibung "Netzwerke, Server, globale IT Infrastruktur". Hätte ich Telefonanlagen betreuen wollen wäre ich Informations- und Telekommunikationselektroniker geworden. Ein bisschen Telefonanlagen gehört zum Ausbildungsberuf einfach dazu. Das ist klar. Aber es macht den Anschein als wäre das hier Kerngeschäft und das wollte ich/wir nicht! So wie es jetzt aussieht werden wir gerade vorbereitet als billige Arbeitskräfte in dem Bereich Telefonanlagen auszuhelfen. Tag zu Tag, bekomme ich weniger Lust zur Arbeit zu gehen und eine Stunde bis zur Arbeit zu fahren, da dann 8 Stunden im Betrieb zu sein, ohne richtige Aufgabe. Ich befürchte, dass uns hier einfach die fehlende Praxis für den Beruf fehlen wird und ich weiß gar nicht wie das im dritten Lehrjahr werden soll mit der Realisierung des Abschlussprojektes, wenn schon jetzt keiner sich für uns verantwortlich fühlt, geschweige denn, dass wir was von den Ausbildungsinhalten wissen oder anwenden können. Wie sollte ich/wir denn jetzt damit umgehen? Ist eine Fortsetzung der Ausbildung in einem anderem Betrieb möglich? Aus der Probezeit sind wir leider schon raus. Mit freundlichen Grüßen
    1 Punkt
  3. Kleiner Hinweis: gebt nicht zu viel interne Informationen aus der Firma preis. Unter Umständen kann man euch da schon nachverfolgen.
    1 Punkt
  4. Die Sache ist einfach wesentlich komplizierter. Die gesamte HR-Abteilung sitzt wie gesagt am anderen Ende von Deutschland. Ich könnte dir jetzt aus dem Stehgreif nicht einmal sagen, wer sein Vorgesetzter ist. Es gibt keine Vertretung und keinen anderen Ansprechpartner für uns. Wenn wir nachfragen interessiert es auch niemanden. Und verantwortlich fühlt sich erst recht keiner. Ich habe in der Telefonabteilung 3!!!! Monate rumgesessen, ohne eine einzige Aufgabe bekommen zu haben. [EDIT C.W.] Azubis interessieren dort niemanden. Eigentlich weiss ich, dass ich kündigen werde, aber bewerben bzw. wechseln ist immer so nervig und aufwendig. :/ Letztendlich geht es nur noch darum herauszufinden, ob sich ein Gang zur IHK lohnt. Mein Kollege neu. möchte das gerne in Angriff nehmen. Ich werde wohl eher kündigen, da ich mir nicht im geringsten vorstellen kann, dass das etwas bringen wird, da die Probleme einfach von zu tiefgreifender und vor allem struktureller, sowie firmenkultureller Natur sind. Was soll die IHK machen? Einen bösen Brief schreiben und dann sagt die Firma: "Ok, ok, dann interessieren wir uns jetzt für die Azubis. Wir richten jetzt Abteilungen ein, die es gar nicht gibt, um den Rahmenplan einzuhalten und am Ende ist für euch auch nicht mehr ein Job als Telefontechniker geplant?"
    1 Punkt
  5. *heißen Rum mit einem Tröpfchen Tee rüber schieb*
    1 Punkt
  6. Bitte wendet euch so schnell wie möglich an die Ausbildungsberater der zuständigen IHK.
    1 Punkt
  7. Ulfmann

    C# OOP Probleme

    Ohne jetzt zynisch werden zu wollen: Das geht mir fast jede Woche so Nein Spaß, mal ernsthaft zu deinem Problem. Ich kann mich noch genau an meine Ausbildung erinnern, als ich vor vermeintlich einfachen Dingen saß, (auch hier im Forum) um Rat gebeten habe und dann mit mir völlig unverständlichen Lösungsvorschlägen zurecht kommen musste. Ich musste auch etwas schmunzeln, als ich Whiz-zarDs Beitrag gelesen hab (der nebenbei bemerkt sehr gut ist). Mein Verständnis für C# hält sich sehr in Grenzen, aber ich konnte alle Schritte gut nachvollziehen. Schmunzeln musste ich deshalb, weil ich gemerkt hab, dass es ihm selbst viel Spaß gemacht hat, fortgeschrittene Programmierkonzepte anhand eines recht überschaubaren Beispiels zu erklären. Du stehst nun da, wolltest eigentlich ein Kartenhaus bauen, fragst, wie man das am besten tut, ob das so ok ist und da kommt ein routinierter Architekt, der dir Statik & thermische Isolierung erklärt und Hinweise für die Integration von Wintergarten und Solaranlage in dein Haus gibt. Allerdings hat er auch erklärt, dass es sein Ansatz wäre und dass man natürlich nicht völlig übertreiben und mit Kanonen auf Spatzen schießen muss. Dazu kommt ja, das ist allerdings meine persönliche Meinung, dass C# unglaublich kompliziert und verwirrend sein kann. Ich arbeite mit Ruby (on Rails) und wenn ich mir vorstelle, wie ich eine CSV einlesen und den Kram anzeigen lassen oder speichern würde, sähe das wesentlich simpler aus solange nichts dynamisch funktionieren muss... Um es kurz zu machen: Du hast jetzt von verschiedenen tollen Sachen gehört, die man machen kann. Mehr solltest gar nicht. Fühl dich nicht aufgefordert, alles bis ins kleinste Detail verstehen zu müssen. Das baut Druck auf, das macht simple Dinge unnötig kompliziert und dann macht es auch keinen Bock mehr. Du wirst solche Momente noch öfter haben. Mach dich damit nicht verrückt, denn das war niemands Absicht. Viel Erfolg bei deinem nächsten Projekt!
    1 Punkt
  8. Den Lebenslauf würde ich definitiv mit beilegen. Links zu den Projekten sind zwar schön, aber bei einer Bewerbung möchte man einen schnellen möglichst kompletten Überblick über den Bewerber haben und nicht über verschiedene Links sich alles zusammensuchen. Die Angabe zum Github-Projekt bzw. Profil kann aber ruhig in den Lebenslauf mit rein.
    1 Punkt
  9. Richtig cool wäre natürlich auch mal, anstatt des Lebenslaufs nur den Link zum Github-Repo anzugeben Wenn das Repo mehrere Projekte enthält, würde ich sie individuell "verlinken" bei dem jeweils dazu passenden Text. Durch den Kontext ist die Chance vielleicht höher, dass auch mal jemand reinschaut. Weist du z.B. schon im Anschreiben auf ein perfekt zum Unternehmen passendes Projekt hin, schreib direkt den Link daneben. Wenn du irgendwo deine "Skills" auflistet, kannst du das mit passenden Links untermauern. Oder falls du ein "Resume" (häufig im amerikanischen Raum verwendet) nutzt, gehören die Links direkt zu den jeweiligen "Accomplishments", um zu "beweisen", dass du das alles wirklich gemacht hast.
    1 Punkt
  10. thereisnospace

    C# OOP Probleme

    Das sehe ich nicht so. Ein Buch beantwortet dir keine Fragen. Sorry, aber leider kann ich nicht nachvollziehen, wie du aus dem Auslesen einer CSV-Datei einen solchen Elefanten machst. Gerade am Anfang der Programmierung ist es normal, dass man keinen 100% Clean Code schreibt und alle möglichen Softwarepatterns versteht und anwendet. Meine ersten Programme in Delphi, wenn ich daran denke, schaudert es mir. Aber ich habe es auf die Beine gestellt bekommen. Auch wenn ich von OOP noch nie gehört habe und die Logik in die Forms geklatscht habe. Wenn man aber das Interesse und die Leidenschaft mitbringt, werden aus diesen anfänglich hässlichen Programmen, immer bessere. Vielleicht fängt man dann an das MVC-Pattern anzuwenden oder beschäftigt sich mit Polymorphie und Kapselung. Du überflutest Tician hier mit Begriffen und Techniken, die einige erfahrene Programmierer in meiner Firma nicht mal zu hören bekommen haben. Sei doch nicht so streng mit jemanden der gerade am Anfang steht.
    1 Punkt
  11. Whiz-zarD

    C# OOP Probleme

    Wieso sollte man dich töten wollen? Softwareentwicklung ist nun mal ein Reifeprozess. Niemand liest nur ein Buch und kann gleich wunderbar sauberen Code schreiben. Mein Code sah zum Anfang auch mies aus und selbst Robert C. Martin, der das Buch "Clean Code" geschrieben hat, sagt von sich aus, dass er nicht die Weisheit mit Löffeln gefressen hat und es auch bei seinen Code-Beispielen sicherlich noch Verbesserungspotenzial gibt aber nur durch Ausprobieren lernt man. Du hast schon richtig erkannt, dass man fürs Einlesen der Datei eine eigene Klasse benötigt. Allerdings gehört die Logik nicht in den Konstruktor. Der Konstruktor dient zur Initialisierung der Klasse. Der Name der Klasse sollte auch die Aufgabe widerspiegeln, was die Klasse tut. "DateiEinlesen" ist vielleicht gut, aber geht es vielleicht noch konkreter? Ich weiß, dass es eine CSV-Datei ist. Vielleicht eher CsvReader? Wobei dieser Name auch wieder sehr allgemein ist. In der CSV-Datei steckt ja eine Tabelle. Welche Daten besitzt die Tabelle? Vielleicht kann man der Tabelle einen Namen geben. Eine CSV-Datei ist ja eine Art der Serialisierung. Das Verfahrung um so eine Tabelle in ein Objekt zu überführen, nennt man auch Deserialiserung. Das kann man ja erst mal im Hinterkopf behalten. Zuerst würde ich mir aber erst mal eine geeignete Datenstruktur überlegen. In der CSV-Datei stecken ja Daten. Ich nehme jetzt mal als Beispiel, dass die CSV-Datei Daten zu Personen beinhaltet: Name;Vorname;Geschlecht;Alter Doe;John;Maennlich;38 Also würde ich erst mal eine Klasse für diese Daten erstellen: public class Person { public string Name { get; set; } public string Vorname { get; set; } public Geschlecht Geschlecht { get; set; } public int Alter { get; set; } } public enum Geschlecht { Maennlich , Weiblich } Nun könnte ich mich darum kümmern, eine(!) Datei einzulesen. Ich habe eine Datenstruktur und ich weiß, dass ich eine CSV-Datei deserialisieren muss. Also könnte man die Klasse z.B. PersonCsvDeserializer nennen. In dieser Klasse soll es eine Methode geben, die Deserialize() heißt. Ich verzichte hier jetzt erst mal bewusst auf ein Interface, weil ich denke, dass es für dich bis hier hin schon kompliziert genug ist. Das Interface werde ich später noch mal erklären. Erst mal kümmern wir uns darum, was wir alles brauchen, um eine Datei zu deserialisieren. Was muss die Klasse PersonCsvDeserializer alles wissen, um eine CSV-Datei deserialisieren zu können? Man könnte vielleicht im ersten Schritt auf die Idee kommen, dass die Klasse den Pfad und Dateinamen benötigt. Mit den Informationen aus dem letzten Absatz könnte ein erster Entwurf so aussehen: public class PersonCsvDeserializer { public IEnumerable<Person> Deserialize(string fileName) { // ... } } Als Rückgabewert habe ich IEnumerable<Person> gewählt, weil IEnumerable<T> ein sehr allgemeines Interface ist und einen Enumerator (auf deutsch: Aufzählung; in anderen Sprachen auch Iterator genannt) zur Verfügung stellt, mit dem wir über die Daten iterieren können (mit der foreach-Schleife). Sowohl IList<T>, ICollection<T>, IDictionary<T>, Array und weitere Klassen implementieren dieses Interface und mehr als über die Daten iterieren wollen wir nicht. Wenn wir später damit mehr machen wollen, können wir es leicht mit Linq in eine Collection, List, Array oder auch in ein Dictionary umwandeln. Die Deserialize()-Methode soll also eine Aufzählung von Personen zurückliefern. Normalerweise macht man es anders, aber aus einfachheit behaupte ich mal frech, dass die erste Zeile in der CSV-Datei immer ein Header besitzt. In der Implementierung überspringe ich den Header per Linq mit der Skip()-Methode. Die Deserialize()-Methode soll also folgendes machen: Die Datei lesen Durch die Datenzeilen iterieren Pro Datenzeile ein Person-Objekt erstellen Die Person-Objekte als Aufzählung zurückliefern Der erste Entwurf könnte daher folgendermaßen aussehen: public class PersonCsvDeserializer { public IEnumerable<Person> Deserialize(string fileName) { IList<Person> result = new List<Person>(); foreach (string line in File.ReadAllLines(fileName).Skip(1)) { string[] elements = line.Split(';'); result.Add(new Person { Name = elements[0], Vorname = elements[1], Geschlecht = (Geschlecht)Enum.Parse(typeof(Geschlecht), elements[2]), Alter = Convert.ToInt32(elements[3]) }); } return result; } } Die Methode macht zwar was sie soll, aber ist sie wirklich übersichtlich? Nicht wirklich. Wir haben hier mehrere Ebenen miteinander vermischt. Wir können also mit dem Refactoring anfangen. z.B. das File.ReadAllLines(fileName).Skip(1) Wofür ist das genau gut? Wenn man den gesamten Kontext kennt, weiß man es zwar aber eigentlich liegt der Code-Abschnitt eine Ebene Tiefer. Es hantiert mit Dateien und hat mit der eigentlichen Aufgabe der Deserialiserung wenig zu tun. Also sollte man diesen Teil in eine separate Methode packen: private IEnumerable<string> ReadDataFromFile(string fileName) { return File.ReadAllLines(fileName).Skip(1); } Somit wandert das Skip(1) in eine tiefere Ebene und interessiert uns in der Deserialize()-Methode nicht mehr. Als nächstes fällt aber auf, dass wir ein String mit Split() in ein Array teilen und aus diesem Array dann die einzelnen Personendaten herausfischen. Diesen Vorgang nennt man auch Parsing. Also könnten wir diesen Teil auch in eine Methode auslagern: private Person Parse(string serializedData) { string[] elements = serializedData.Split(';'); return new Person { Name = elements[0], Vorname = elements[1], Geschlecht = (Geschlecht)Enum.Parse(typeof(Geschlecht), elements[2]), Alter = Convert.ToInt32(elements[3]) }; } Unsere Klasse sieht dann bis jetzt folgendermaßen aus: public class PersonCsvDeserializer { public IEnumerable<Person> Deserialize(string fileName) { IList<Person> result = new List<Person>(); foreach (string serializedData in ReadDataFromFile(fileName)) { Person person = this.Parse(serializedData); result.Add(person); } return result; } private IEnumerable<string> ReadDataFromFile(string fileName) { return File.ReadAllLines(fileName).Skip(1); } private Person Parse(string serializedData) { string[] elements = serializedData.Split(';'); return new Person { Name = elements[0], Vorname = elements[1], Geschlecht = (Geschlecht)Enum.Parse(typeof(Geschlecht), elements[2]), Alter = Convert.ToInt32(elements[3]) }; } } Nun ist Deserialize() doch recht gut lesbar. Wir lesen die Daten aus der Datei, parsen die Daten und erhalten ein Person-Objekt, welches wir dann in eine Liste packen und zum Schluss geben wir die Liste zurück. Es gäbe hier noch weiteres Verbesserungspotenzial aber ich belasse es erst mal hierbei. Ein paar Hinweise gebe ich aber noch: Fehler-Handling? Was passiert, wenn z.B. die Datei nicht existiert? Ist das erzeugte Objekt List<Person> wirklich eine gute Wahl? Angenommen, wir haben es mit einer riesigen CSV-Datei (mehrere Gigabytes) zu tun, die größer ist, als unser Arbeitsspeicher. Hier schmeiße ich mal das "yield return"-Schlüsselwort in den Raum. Auch ist das indexierte Zugreifen auf das Array in der Methode Parse() nicht wirklich glücklich gelöst. Was passiert nämlich, wenn mal eine Spalte in der Datei hinzukommt? Dann muss man ja auch den Code anpassen. Das will man aber eigentlich gar nicht. Zu diskutieren wäre auch, ob die Variable fileName nicht doch besser eine Instanzvariable sein sollte, die per Konstruktor reingereicht wird. Es fällt ja auf, dass die Methoden Deserialize() und ReadDataFromFile() den Dateinamen benötigen. Also stellt fileName ja eine gewisse Abhängigkeit dar, die die Klasse benötigt, um arbeiten zu können. Als Überlegung kannst du ja selber mal schauen, wie man mit solchen Situation umgehst. Um später im Hauptpgramm alle Personen zu iterieren könntest du nun folgendes schreiben: static void Main(string[] args) { string sourcePath = Environment.GetFolderPath(Environment.SpecialFolder.Desktop) + "\\blabla"; IEnumerable<string> fileNames = Directory.GetFiles(rootPath, "*.csv"); PersonCsvDeserializer deserializer = new PersonCsvDeserializer(); foreach(string fileName in fileNames) { IEnumerable<Person> persons = deserializer.Deserialize(fileName); foreach (Person person in persons) { // ... } } } Nach dem selben Prinzip, wie bei der PersonCsvDeserializer-Klasse kannst du ja mal überlegen, wie man nun diesen Code refactoren an. Ab hier wird es noch etwas technischer und tiefgreifender. Ich möchte dir noch zwei Techniken zeigen, die du aber erst mal nicht umsetzen brauchst. "Inversion of Control" und "Dependeny Injection" In der Klasse PersonCsvDeserializer fällt auf, dass die Klasse von einer Datei abhängig ist aber die Daten können vielleicht aus einer Datenbank kommen oder wir schreiben die CSV-Daten direkt in eine grafische Oberfläche. Möchte man jetzt für jeden Anwendungsfall eine eigene Klasse schreiben? Eigentlich nicht. Die Abhängigkeit zur Datei muss also aufgelöst werden. Das .Net-Framework bietet ja die abstrakte Klasse TextReader, die so ziemlich alles darstellen kann. Ein Reader, der eine Datei liest oder aus einem TCP-Stream oder aus einer Datenbank, etc. Anstatt also den Dateinamen reinzureichen, könnte man auch ein TextReader reinreichen. Hier mal ein Beispiel, wie so eine Klasse aussehen könnte: public class PersonCsvDeserializer { private TextReader reader; private bool isHeaderSkipped; public PersonCsvDeserializer(TextReader reader) { this.reader = reader; } public IEnumerable<Person> Deserialize() { string serializedData; while ((serializedData = this.ReadNextData()) != null) { Person person = this.Parse(serializedData); yield return person; } } private string ReadNextData() { string serializedData = this.reader.ReadLine(); if (!this.isHeaderSkipped) { this.isHeaderSkipped = true; return this.ReadNextData(); } return serializedData; } private Person Parse(string serializedData) { string[] elements = serializedData.Split(';'); return new Person { Name = elements[0], Vorname = elements[1], Geschlecht = (Geschlecht)Enum.Parse(typeof(Geschlecht), elements[2]), Alter = Convert.ToInt32(elements[3]) }; } } Die Main-Methode sieht dann so aus: static void Main(string[] args) { string sourcePath = Environment.GetFolderPath(Environment.SpecialFolder.Desktop) + "\\blabla"; IEnumerable<string> fileNames = Directory.GetFiles(rootPath, "*.csv"); foreach(string fileName in fileNames) { using (TextReader reader = File.OpenText(fileName)) { PersonCsvDeserializer deserializer = new PersonCsvDeserializer(reader); IEnumerable<Person> persons = deserializer.Deserialize(); foreach (Person person in persons) { // ... } } } } Zugegeben, in diesem Beispiel ist die Klasse PersonCsvDeserializer etwas komplizierter geworden aber es ist jetzt egal, woher die Daten stammen, solange wir ein TextReader in den Konstruktor schieben. Das reinrechen der Abhängigkeit in den Konstruktor nennt sich auch "Dependeny Injection". In diesem Beispiel habe ich auch das yield return verwendet. Da wir jetzt nur noch maximal den Speicher für ein Person-Objekt verbrauchen, könnte die Klasse eigentlich nun unendlich viele Daten deserialisieren. Ein Problem stellt aber immer noch die Indexierung des Arrays dar aber das überlasse ich jetzt dir. Das Interface Das letzte, was ich noch schreiben wollte, wäre ein geeignetes Interface für den Deserializer. Wollen wir jetzt mehrere Deserializer schreiben oder einen Deserializer als Abhängigkeit in eine Klasse reinreichen, ist ein Interface geeignet, damit es später egal ist, um welchen Deserializer es sich handelt. Man könnte sich ja auch vorstellen, dass die Daten nicht in einer CSV-Datei stecken, sondern in einer XML-Datei. Dafür wäre folgendes Interface recht nützlich public interface IDeserializer<T> { IEnumerable<T> Deserialize(); } Mit diesem Interface könnten wir sogar das hässliche using im Hauptprogramm wieder loswerden. Ich finde, das using stört im Lesefluss. Wir haben ja jetzt eine Klasse, die CSV-Daten aus unterschiedlichsten Quellen von Personen deserialisieren kann. Was hindert uns nun daran, einen weiteren Deserializer zu bauen, der aus Dateien deserialisiert? Beispiel: public class PersonCsvFileDeserializer : IDeserializer<Person> { private string fileName; public PersonCsvFileDeserializer(string fileName) { this.fileName = fileName; } public IEnumerable<Person> Deserialize() { using (TextReader reader = File.OpenText(fileName)) { PersonCsvDeserializer deserializer = new PersonCsvDeserializer(reader); return deserializer.Deserialize(); } } } Das using wurde nach PersonCsvFileDeserializer und somit eine ebene tiefer verschoben. Wenn du Dependecy Injection verstanden hast, dann würde dir auffallen, dass die Zeile PersonCsvDeserializer deserializer = new PersonCsvDeserializer(reader); eigentlich böse ist, da es eine Abhängigkeit darstellt, die wiederum in den Konstruktor gehört. Ich habe sie aber erst mal hier drinnengelassen, weil das sonst wieder bedeuten würde, dass das using wieder ins Hauptprogramm rein müsste. Eigentlich müsste man sich eine Fabrik-Methode ausdenken, die den PersonCsvFileDeserializer zusammenbaut. Die habe ich hier aber weggelassen. Die kannst du dir ja ausdenken. Das Hauptprogramm würde dann so aussehen: static void Main(string[] args) { string sourcePath = Environment.GetFolderPath(Environment.SpecialFolder.Desktop) + "\\blabla"; IEnumerable<string> fileNames = Directory.GetFiles(rootPath, "*.csv"); foreach(string fileName in fileNames) { PersonCsvFileDeserializer deserializer = new PersonCsvFileDeserializer(fileName); IEnumerable<Person> persons = deserializer.Deserialize(); foreach (Person person in persons) { // ... } } } Das wäre doch schon wieder ein Schritt übersichtlicher. Wie du also siehst, haben wir allein nur für das Einlesen von den CSV-Dateien drei Klassen: Person PersonCsvDeserializer PersonCsvFileDeserializer und ein Interface: IDeserializer<T> geschrieben. Man braucht also kein mega großes Projekt, um mehrere Klassen zu schreiben. Es reicht auch schon was ganz einfaches. Man sollte sich immer bewusst machen, dass Klassen immer nur eine Aufgabe machen sollten und Methoden Teilaspekte dieser Aufgabe sind und sie sollten auch nicht mehr machen, als eine Sache. Es macht auch nichts, wenn man zum Anfang Spagetticode schreibt und diesen später nach und nach einem Refactoring unterzieht. Niemand ist perfekt und niemand schreibt perfekten Code. Man fängt also immer erst mal an und arbeitet sich Schritt für Schritt an eine geeignete und saubere Lösung. Selbst meine Lösung ist mit Sicherheit nicht perfekt und ich habe auch nicht die Weisheit mit Löffeln gefressen. Wenn du mein Beitrag richtig verfolgt haben solltest, hast du vielleicht auch gemerkt, dass ich erst mal eine Lösung geschrieben habe und sie dann nach und nach verfeinert und verbessert habe. Das Wissen kommt erst mit Erfahrung und Erfahrung sammelt man nur, indem man es ausprobiert und darüber mit anderen diskutiert. Also trau dich. So, das reicht auch fürs erste. Ich denke, das ist erst mal genug Input.
    1 Punkt
  12. Guybrush Threepwood

    Geld

    Das geht für die ganzen Nutten und Koks drauf
    1 Punkt
Diese Rangliste nutzt Berlin/GMT+01:00 als Grundlage

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...