1
0
Fork 0
Go to file
Philipp Kotte 8182bd7faf Merge branch 'main' of https://gitty.informatik.hs-mannheim.de/2211945/WIZARD_PR2_DOP into merge 2023-10-11 17:31:15 +02:00
Domain Merge branch 'main' of https://gitty.informatik.hs-mannheim.de/2211945/WIZARD_PR2_DOP into iss#28 2023-10-11 17:16:59 +02:00
Facade to String hinzugefügt und Spiel erweitert 2023-10-11 11:15:39 +02:00
Infrastructure Strukturanpassung in Persistenz.java 2023-10-11 17:04:28 +02:00
Test Neue Struktur für den Block. Testklassen für alle bisher vorhandenen Klassen 2023-10-10 21:22:33 +02:00
UI to String hinzugefügt und Spiel erweitert 2023-10-11 11:15:39 +02:00
.DS_Store Neue Struktur für den Block. Testklassen für alle bisher vorhandenen Klassen 2023-10-10 21:22:33 +02:00
.gitignore Änderungen 2023-10-11 16:56:05 +02:00
Main.java Systemausgabe für Laden der WIZARD_DATA_Wizard.ser 2023-10-11 13:59:46 +02:00
PR2L - U01.pdf Anleitung Dopatka Übung Nr 1 2023-10-05 23:19:54 +02:00
README.md Temaplate für die Anforderungen von einer Struktur für Klassen von Dopatka hinzugefügt 2023-10-11 10:28:42 +02:00

README.md

Wizard PR2 Prof. Dopatka

Gruppe Studienleistung bereits vorhanden

Teilnehmer

  • Kai Sellman
  • Odin Selimovic
  • Mohammad Hawrami
  • Philipp Kotte

Dopatka Regeln wie Klassen anzulegen sind

Aufbau

  1. statische Konstante
  2. statische Attribute(zB. zähler)
  3. Attribute jedes Objektes
  4. Konstruktoren (default und spezifische)
  5. statische Methoden
  6. Getter und Setter
  7. @Overrides
  8. öffentliche Methodes
  9. Hilfsmethoden (privat)

Template

/*------------------------------------------*/
// statische Konstanten
/*------------------------------------------*/

/*------------------------------------------*/
// statische Attribute(zB. zähler)
/*------------------------------------------*/

/*------------------------------------------*/
// Attribute jedes Objektes
/*------------------------------------------*/

/*------------------------------------------*/
// Konstruktoren (default und spezifische)
/*------------------------------------------*/

/*------------------------------------------*/
// statische Methoden
/*------------------------------------------*/

/*------------------------------------------*/
// Getter und Setter
/*------------------------------------------*/

/*------------------------------------------*/
// @Overrides
/*------------------------------------------*/

/*------------------------------------------*/
// öffentliche Methodes
/*------------------------------------------*/

/*------------------------------------------*/
// Hilfsmethoden (privat)
/*------------------------------------------*/

Für das Arbeiten mit geschützten Mainbranch

Wenn Änderungen durchgeführt werden müssen, kann dieses nicht direkt auf dem main-Branch gepusht werden sondern muss mit einem Separatem Branch und Pull-Request durchgeführt werden. Die Schritte um einen Feature-Branch zu erstellen sind folgende:

1. Erstellen eines neuen Branch auf Basis des aktuellen main:

git checkout -b <Branchname>

Switchen zwischen den branches: git checkout <Branchname>

Hier wird das Feature Ausgearbeitet und fertiggestellt.

2. Aktualisieren mit Mainbranch

Besonders wenn eine Weile an dem Feature Branch gearbeitet wurde, können bereits Änderungen auf Main durchgeführt worde sein. Daher wird vor dem Pull Request der Feature-Branch mit dem Main-Branch gemerget.

Mergen des Main-Branch in den Feature Branch git pull origin main

3. Pull Request

Danach damit wir alle die Changes mitbekommen muss ein Pull Request auf Gitea gestellt werden. Im zuge dessen findet eine Code Review von einem beliebigen Teammitglied statt, damit dieser frei gegeben werden kann.

Anmerkungen von Dopatka im Forum

Kartenstapel

  1. Die Methode getObsersteKarte soll nur den wert zurückgeben, diese aber nicht ziehen
  2. Die Methode mischen() kann gelöscht werden da die Spieler keine möglichkeit haben sollen dies selbst anzustoßen. Vorschlag -> wir behalten sie als private und rufen sie an der benötigten Stele auf

Karten

  1. Magierkarte wurde zu Zaubererkarte umbenannt

Spieler

  1. Speicherung der Karten des Spieler in der Klasse Spieler
  2. Die Namen der Spieler müssen mindestens 3 und dürfen maximal 9 Zeichen lang sein a-z A-Z 0-9 -_

Spiel

  1. Die Methode getSpielerAmZug(): String[] soll einen Spieler mit all seinen Daten representieren und alle Daten des Spielers zurückgeben

  2. Es dürfen während des Spiels keine Spieler gelsöscht oder hinzugfügt werden

Allgemein

  1. toString methode für jede Klasse