Whiz-zarD

Ich habe schon in einigen Firmen gearbeitet und habe auch einige Arbeitszeugnisse aber in keinem wird die Firma beschrieben und die Aufgabenbereiche hat man dann auch auf einen Satz reduziert. Da lässt sich auch nicht so viel herauslesen, was man gemacht hat. Da steht dann so viel, wie Ja, als Mechatroniker (mein damaliger Beruf) sollte man Konstruktionszeichnungen lesen können. So viel nützliches bietet also das Arbeitszeugnis nicht. Laut einigen Quellen im Internet ist Deutschland auch hier mal wieder ein Exot. Kein anderes Land kennt sowas, wie Arbeitszeugnisse. Das hatte ich mir auch schon fast gedacht. Für viele Personaler scheint es lästig zu sein, so etwas zu schreiben und die Mitarbeiter selbst beauftragen, es zu schreiben, ohne es sich noch mal genauer anzuschauen. Also eigentlich nur ein Stück Papier, womit man sein A***** abwischen kann.

Ich habe es hier schon öfters gelesen, dass man in Betrieben anfordern kann, ein gutes Arbeitszeugnis zu bekommen. Auch kann man es selbst schreiben, wie in diesem Thread z.B. Da fragt man sich schon, welchen Sinn und Zweck überhaupt noch Arbeitszeugnisse haben, wenn man diese sowieso grundlegend und sogar gewollt Manipulieren kann? Welchen Mehrwert haben dann die Firmen, wenn sie so ein Zeugnis lesen? Sie können sich ja nicht mal sicher sein, dass das Zeugnis der Wahrheit entspricht. Wozu also das Ganze? Das ist doch letzen Endes nur ein Nachweis, dass ich in Firma X gearbeitet habe. Mehr nicht. Dafür braucht man aber kein Arbeitszeugnis, sondern nur eine offizielle Bestätigung. Ist das Zeugnis nur mal wieder der deutschen Bürokratie geschuldet oder läuft das im Ausland so ähnlich?

Wieso ist "Reisen" eine Ein- und Ausgabe?

Das "Pfeil auf Pfeil zeigen" ist schon richtig. In Rechtecke werden Operationen abgebildet. Man fängt ja nicht immer von vorne mit dem Tanken an, nur weil der Tank noch nicht voll ist. Die Operation "Tanken" soll ja so lange laufen, bis der Tank voll ist, daher soll sie ja auch so lange laufen, bis die nächste Operation erreicht ist. Das angeblich "moderne" Diagramm ist Mist, weil eine Abfrage, ob der Tank voll ist, keine Operation ist und somit auch gegen die ISO-Norm verstößt. Das kannst du auch im Wiki-Artikel lesen: https://de.wikipedia.org/wiki/Programmablaufplan

Sorry aber das bieten sie jeden Bäcker mit einer Mehlallergie an. Die Wirtschaft schreit "Fachkräftemangel!" also wird jeder in so eine Umschulung gesteckt. Ich stelle mir auch die Frage, was es noch bringen soll, mit 50 eine Ausbildung anzufangen? Nach einer FIAE-Ausbildung fängt man dann als Junior Entwickler an und bei 50-jährigen wird man wohl nicht mehr über diesen Status hinauskommen, daher wird so ein Entwickler nicht wirklich rentabel für ein Unternehmen sein. Selbst wenn du die Ausbildung absolvierst, sehe ich wenig bis keine Chancen, überhaupt einen Job zu bekommen.

Aus eigener Erfahrung kann ich sagen, dass beide Punkte ein Trugschluss sind. Das Argument "Wenn man es selbst entwickelt, dann hat man keine Abhängigkeiten" habe ich schon so oft gehört und jedes Mal war es ein Fehler. Das Problem ist, dass man sich zu viel ins Unternehmen holt, was gar nicht das Kerngeschäft des Unternehmens ist. Als Beispiel kann ich die Firma nennen, wo ich gerade arbeite. Sie haben ihr O/R-Mapper selbst entwickelt, genau aus den genannten Gründen. Das Ding wird zunehmend ein gigantisches Problem, weil der performancetechnisch einfach nur Mist ist. Wir entwickeln eine Software für Banken. Wir müssen uns also nicht nur mit unserem Kerngeschäft auseinandersetzen, sondern haben noch Technologien, wie z.B. der O/R-Mapper warten. Sprich, wir können uns nicht zu 100% mit den Aufgaben der Kunden beschäftigen, weil wir selber intern zu viel an der Backe haben. Kostengünstige Wartung erreicht man auch nicht, indem man die Applikation selbst entwickelt, denn irgendwer muss man auch den Entwickler dafür bezahlen. Also entweder kommandiert man ein Entwickler ab, der sich eigentlich um das Tagesgeschäft kümmern sollte und somit für diese Zeit kein Geld in die Kassen spült oder ich muss einen einstellen, der sich ausschließlich mit der In-House-Software beschäftigt. Nur weil man keine Lizenzverträge hat, heißt es noch lange nicht, dass eine Software günstiger ist. Eine In-House-Lösung kann auch sehr teuer werden. In den meisten Fällen wird diese nur Stiefmütterlich behandelt. Sprich, die wird halt irgendwie hingefrickelt. Interessiert doch eh keinen. Tests werden vernachlässigt, weil sie überflüssig sind und Geld kosten. Also lässt man sie weg. Ein Refactoring findet dann auch nicht statt. Läuft doch. Jeder frickelt neue Funktionen rein und nach einem Jahr ist die Applikation instabil, unwartbar und nur noch lästig. Also ja, in der Theorie hast du recht (reicht vielleicht auch bei der Abschlussarbeit) aber die Praxis sieht leider anders aus.

Die Frage habe ich mir auch gerade gestellt. Ich finde auch, die 70 Stunden, für so ein Projekt, sind schon sehr sportlich, wobei die Implementierung nur eine Woche beinhaltet. z.B. zum Thema "Authentifizierungs-, Rollen- und Rechtesystemen" kann man sich schon monatelang beschäftigen.

Was heißt für dich "Programm-Start"? Wo ist denn das zu finden, was du meinst?

Das schon eher (auch wenn das auch nicht nicht sauber ist). Ein Hinweis, dass die beiden genannten Zeilen nicht in die Fight-Klasse gehören, ist auch deren Funktion. Du bewegst den Spieler und ein Monster erscheint. Das ist aber noch vor dem Kampf und somit verletzt man das sog. Single-Responsibility-Prinzip. Sprich, die Klasse hat mehr als eine Zuständigkeit, indem die Klasse den Spieler bewegt, das Ereignis auslöst und den Kampf an sich.

Konstruktoren sollte keine Logik besitzen. Wie der Name schon sagt, dient er zur Konstruktion eines Objektes. Daher sollte der Konstruktor auch nur dafür verwendet werden. Sprich, die Zeilen: player.MoveTo(World.LocationById(World.location_id_fight)); MonsterAppear(this, new EventArgs()); Sollten da raus.

Du reichst Player und Monster in den Konstruktor der Fight-klasse rein und speicherst diese dann als Membervariable in dieser Klasse ab.

Die Methode ist doch in der Spieler-Klasse definiert, dann kannst du doch die Eigenschaften/Methoden der Klasse aufrufen public int Attack(Monster monster) { var attack = this.GetDamage(); monster.TakeDamage(attack); return monster.CurrentHitpoints; } private int GetDamage() { // Logik }

Das ist eigentlich auch der richtige Weg. Die Attack()-Methode in der Player-Klasse verursacht einige Probleme. Zum einen vermischt man Datenhaltung mit der Logik. Wenn man es weiterspinnt, dann wird es ja bei der Attack()-Methode nicht bleiben. Dann gibt es vielleicht noch eine Talk()-, eine Walk()-, eine Use()-, etc. Methode. Die Klasse hat dann mehrere Zuständigkeiten. Sie hält also nicht nur die Daten des Spielers, sondern ist auch noch für den Kampf, fürs Reden, fürs Laufen, etc. zuständig. Darüber hinaus wird die Player-Klasse von der Monster-Klasse abhängig. Das mag vielleicht in einem einigen Projekt nicht so schlimm sein aber wenn man z.B. die Monster in ein separates Projekt auslagert, so wird es schon etwas problematischer, wenn man dann die Player-Klasse einzeln testen möchte. Eine Klasse, die den Kampf koordiniert, dient dann als "Verbindungsstück" (Integration) zwischen Spieler, Monster und ggf. der UI und die Player- und Monster-Klassen können als "dumme" Objekte (POCOs) behandelt werden und brauchen dann keinerlei Logik.

INotifyPropertyChanged Ein anderes Stichwort wäre "Data Binding"

Wenn du es vernünftig machen willst, dann ja, denn das sind die Grundkonzepte der Objektorientierung. Wenn du fehlerhaften, unwartbaren, unübersichtlichen, komplizierten und verdoppelten Code produzieren willst, dann nein. Weil du dich strikt weigerst, etwas neues zu lernen: Man könnte dir von Patterns, etc. erzählen aber das ist einfach vergeudete Mühe, weil du die sowieso nicht einsetzen willst.