Whiz-zarD

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.

Ein weiterer Tipp: Solche Konstruktoren, wie z.B. public Player(int curHP, int maxHP, int gold, int curExp, int maxExp, int level, int attack) { ... } Sind unter C# nicht nötig und auch beim Aufruf schlecht lesbar. Keiner wird auf den ersten Blick verstehen, welche Parameter was ist: private Player _player = new Player(20, 20, 0, 0, 10, 1, 2); Man muss den Konstruktor kennen, um zu wissen, was z.B. die letzte 2 bedeutet. C# bietet hier den Objectinitializer, der das Ganze lesbarer macht: private player = new Player { CurHP = 20, MaxHP = 20, Gold = 0, CurExp = 0, MaxExp = 10, Level = 1, Attack = 2 }; Anstatt eine List<Monster> zu nehmen, um darüber dann zu iterieren, um das jeweilige Monster mit der Id herauszusuchen, verwendet ein Dictionary<int, Monster>. Beispiel: public Dictionary<int, Monster> monsters = new Dictionary<int, Monster> { { monster_id_wolf, new Monster(monster_id_wolf, "Wolf", 10, 10, 1, 10, 2, 1) }, { monster_id_bee, new Monster(monster_id_bee, monster_id_bee, "Bee", 1, 1, 1, 1, 1, 1) } } Dann brauchst du die MonsterById()-Methode nicht mehr, sondern kannst direkt mit monsters[monster_id_wolf] darauf zugreifen. Natürlich kannst du auch hier den oben genannten Tipp mit dem Konstruktor nehmen. Ansonsten ist da noch sehr viel, was man anders machen sollte aber darüber zu reden bringt wohl nichts.

Und das ist schon falsch...

Ich habe keine hohen Ansprüche. Das Problem ist einfach, dass dir nicht klar ist, was du da eigentlich tust und das wird zu Frustration führen. Du willst auch nichts dazu lernen, indem du dich strikt weigerst neue Dinge zu lernen und mit deinem Laienwissen bist du noch nicht so weit, ansatzweise sowas aufbauen zu können. Das fängt schon damit an, dass du Klassen und Membervariablen static machst, ohne den Sinn dahinter zu verstehen und was das bedeutet, wenn du diese static machst.

Auweia. Da ist so ziemlich alles falsch, was man nur falschmachen kann. Ich komme erst am Wochenende dazu, etwas längeres zu schreiben aber man sieht schon deutlich, dass dies für dich einige Nummern zu groß ist. Sorry, aber fange mit was kleinerem an. Ehrlich, du machst dir keine Freude damit.

Web-Applikationen sind auch nicht mehr das "Nonplusultra". Der Trend geht in Richtung Mobile-First. D.h. es wird zuerst eine Mobile-App entwickelt, bevor man eine Web-App entwickelt. PHP- und ASP.NET-Anwendungen sind auch schon auf dem Rückzug. Sie werden uns zwar noch viele Jahre begleiten aber der Trend in Web-Apps geht in Richtung sog. Single-Page-Applikationen (SPA). SPAs haben den Vorteil, dass der Server entlastet wird, indem das Rendering auf dem Client stattfindet. D.h. der Server schickt nur noch die rohen Daten zum Client (Browser) und der Browser bastelt daraus selbst das HTML-Dokument. Für SPAs braucht man auch keinen dicken Webserver ala Apache, sondern es reicht auch was leichtgewichtiges, was die Anfragen annimmt und jemandem damit beauftragt. In der .NET-Welt gibt es z.B. NancyFx, was einen HTTP-Request annimmt und verarbeiten kann. NancyFx ist angelehnt an das Ruby-Projekt Sinatra. NancyFx könnte also z.B. ein HTTP-Request entgegennehmen und es an einen Microservice weiterleiten und das Ergebnis zurück zum Client schicken. Auf dem Client läuft dann ein Framework ala AngularJS oder React, mit denen dann die HTML-Dokumente erstellt werden. Klassische WinForms Anwendungen gibt es zwar noch in der Business-Welt aber die sind eher historisch begründet. Wir entwickeln auch noch eine aber wir haben mit der Planung der nächsten Generation angefangen und die deutliche Mehrheit unserer Kunden (Banken) wollen keine Desktop-Applikation, weil sie damit einen höheren Aufwand haben, da sie virtuelle Desktops bereitstellen müssen. Auch der Trend bei unseren Kunden geht also hin zu mobilen Endgeräten. Also nein, auf Desktop-Anwendungen würde ich heutzutage nicht mehr setzen, es sei denn, du hast da was sehr spezielles, was in einem Browser nicht funktioniert oder vom Vorteil wäre, wenn es auf einem Desktop läuft aber selbst bei 3D-Grafiken ist WebGL da schon sehr weit. Man muss auch berücksichtigen, dass selbst bei Ottonormalverbrauchern der Trend in Richtung Mobile-Geräten geht und da sollte man sich schon fragen, ob es Klug ist, eine sehr große Klientel auszugrenzen.

Er ist über 30. Mit Sicherheit geht er nicht mehr zur Schule...

Ich sehe das ähnlich, wie @Gottlike. Dein Kenntnisstand ist noch nicht so weit, um so ein Projekt anzugehen. Ich will nicht zu Nahe treten aber dir ist OOP offenbar immer noch nicht so wirklich klar. Das fängt schon, wie gesagt, mit der statischen Klasse für den Spieler an. Wieso soll sie statisch sein? Das macht überhaupt keinen Sinn. Statische Klassen machen nur in wenigen Situationen wirklich Sinn. In der Praxis werden sie aber oft dann verwendet, wenn der Entwickler gar nicht weiß, was er eigentlich tut. Das nächste ist, dass dir gar nicht klar ist, wie man Programmlogik von der Oberfläche trennt. Die Main-Methode einer klassichen WinForms-Anwendung besteht lediglich nur aus drei Zeilen Code: static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new Form1()); } Was du noch in die Main()-Methode reinkloppen willst, erschließt sich mir erst mal nicht. Ein erfahrener Entwickler wird mit Sicherheit diese Methode noch erweitern, z.B. mit der Initialisierung eines IoC-Containers oder sonstigen Frameworks aber das sind Techniken, mit denen du mit deinem Wissensstand noch nichts anfangen kannst. Ich vermute auch mal, dass dir die ganzen Designpatterns nichts sagen. Wenn man dein Beitrag auch durchliest, machst du dir viel mehr Gedanken, um die Oberfläche, anstatt um die Architektur der Software, daher ist das Ziel noch viel zu hochgesteckt. Fange mit Konsolenanwendungen an, um überhaupt OOP zu verstehen und um ein Gefühl dafür zu bekommen. Eine Oberfläche ist eigentlich nur ein schmuckes Beiwerk für eine Software. Ich persönlich würde vielleicht vorschlagen, eine API für Schach zu entwerfen. Ohne Oberfläche. Also überlegen, welche Datenstruktur ein Schachbrett und die Figuren haben könnten und dann noch Logiken, die ermitteln, welche Figur welchen Zug machen kann. Testen kann man das Ganze ja auch mit Unittests. Eine grafische Oberfläche muss ja nicht immer eine gute Note bedeuten aber keine Ahnung, ob das nicht schon zu schwer ist. Eine einfachere Form wäre Dame oder noch einfacher: Tic-Tac-Toe.

Sofern Microsoft nicht die Schnittstellen ändert und ältere Clients die neue Schnittstelle nicht implementiert haben...

Okay. Schade. Trotzdem danke.

Genau

Nur irgendwie nervt es. Auch eine Frage wird schnell zu einem Thread, da dort dann weitere Fragen gestellt werden und dann wird es schnell unübersichtlich, was nun die neueste Antwort bzw. Frage ist. Jedes Mal muss man den "Nach Datum sortieren"-Button klicken, um den chronologischen Verlauf zu verstehen.

Kann man irgendwo angeben, dass das Forum die Posts nach standardmäßig Datum sortieren soll und nicht nach Bewertung? Das macht mich immer ganz wahnsinnig.