# Robot Factory for PR2

* [Teilnehmer](#teilnehmer)

* [Overview](#overview)
  * [Packages](#packages)
  * [Sidefiles](#sidefiles)
* [Aufgabe](#aufgabe)


## Teilnehmer:

- Philipp Kotte Matr. : 2211945;
- Cedric Hermann Matr. : 2210943;
- XXXXXXX XXXXX Matr. : XXXXXXX;

# Overview

## Packages
* ### [Domain](#domain)
  * [R2D2](#-klasse-r2d2-)
    * [R2D2Test](#-testklasse-r2d2test-)
  * [C3P0](#-klasse-c3po-)
    * [C3POTest](#-testklasse-c3potest-)
  * [RobotBasics]
  * [Robot](#-interface-robot-)
  * [RobotControl](#-interface-robotcontrol-)
  * [RobotControl](#-interface-robotinstructions-)
* ### [Facade](#facade)
  * [Factrory](#-klasse-factory-)
* ### [Infrastructure](#infratructure)
  * [Persistenz](#-klasse-persistenz-)
* ### [robot]
  * ### [exceptions]
    * [RobotException]
    * [RobotIllegalStateException]
    * [RobotMagicValueException]
  * ### [interfaces](#-interfaces-)
    * [Robot]
    * [RobotControl]
    * [RobotInstructions]
    * [Sorting] vorläufig
* ### [UI](#ui)

## Sidefiles
* [Main](#-klasse-main-)
* [makefile](#-makefile-for-Git-updates-)

## Domain
<h2 align="center"> Klasse R2D2 </h2>

### Variables:
`--not set yet--`
___

### Methods:
`public R2D2():R2D2`

<h2 align="center"> TestKlasse R2D2Test </h2>

### Variables:

`public int id`

`public String name`

`public R2D2 Herbert`
___ 

### Methods:

`@BeforeEach`
`setup():void`

`@Test`

`getId():void`

`getName():void`

`triggerPowerSwitch():void`

`iPowerOn():void`



<h2 align="center"> Klasse C3PO </h2>


### Variables:
`--not set yet--`
___

### Methods:
`//construtor`

`public C3PO(): C3PO`



## facade

<h2 align="center"> Klasse Factory </h2>

### Variables:
`--not set yet--`
___

### Methods:
`--not set yet--`

## Infrastructure

<h2 align="center"> Klasse Persistenz </h2>

### Variables:
`--not set yet--`
___

### Methods:
`--not set yet--`

## robot

### exceptions

<h2 align="center"> Class RobotException </h2>

### Methods:
`public RobotException():Exception`

<h2 align="center"> Class RobotIllegalStateException </h2>

### Methods:
`public RobotIllegalStateException():RobotException`

<h2 align="center"> Class RobotMagicValueException </h2>

### Methods:
`public RobotMagicValueException():RobotException`

### interfaces

<h2 align="center"> Interface Robot </h2>

### Methods:
`--not set yet--`



<h2 align="center"> Interface RobotControl </h2>

### Methods:
`--not set yet--`

<h2 align="center"> Interface RobotInstructions </h2>

### Methods:
`--not set yet--`


##  UI

<h2 align="center"> Klasse UI </h2>

### Variables:
`--not set yet--`
___

### Methods:
`--not set yet--`




<h2 align="center"> Klasse Main </h2>

### Variables:
`--not set yet--`
___

### Methods:
`--not set yet--`

<h2 align="center"> makefile for Git updates </h2>

### Variables:
`--not set yet--`
___

### Methods:

`update_readme:`

`update_make:`

`update_all:`



## Aufgabe

PR2-Aufgabe Roboterfabrik
(ursprüngliche Autoren: Sebastian Tschirpke und Steffen Hennhöfer; mit Erweiterungen von Oliver Hummel)
Nach Abschluss Ihres Bachelorstudiums sind Sie auf Jobsuche. In einem Zeitungsartikel 
lesen Sie, dass die Firma ASDF123-Roboter AG, junge und kreative Mitarbeiter für den 
Aufbau einer Roboterfabrik sucht. Von der Stellenausschreibung ganz hingerissen, machen 
Sie sich sofort auf den Weg und reichen Ihre Bewerbungsunterlagen ein. Tatsächlich 
meldet sich die Firma kurz darauf bei Ihnen und lädt Sie zu einem Bewerbungsgespräch ein. 
Für Sie läuft scheinbar alles perfekt und Sie können es kaum erwarten Ihren zukünftigen 
Arbeitgeber von Ihren Qualitäten zu überzeugen. Jedoch zeigt dieser keinerlei Interesse an 
Ihren Zeugnissen, sondern knüpft vielmehr Ihre Einstellung an die Lösung folgender Aufgabe 
für die Sie Klassen auf der Domänenebene implementieren und testen sollen:
Die Firma möchte eine neue Roboterfabrik aufbauen und benötigt dazu ein Softwaremodell, 
welches den Produktionsprozess und die Roboter simuliert. Es handelt sich nur um eine 
einzige Fabrik mit einer Fabrikmethode, die flexibel auf Bestellungen der Kunden reagieren 
kann. Die Roboterfabrik bietet ihren Kunden zunächst zwei verschiedene Modelle an, beide 
aus der Star-Wars-Produktreihe: die Modelle heißen C3PO und R2D2 und sollen gemeinsam 
genutzte Funktionalität von einer Superklasse erben. Alle Roboter haben eine einfache 
Schnittstelle Robot, mit der sie gesteuert werden können. Diese Schnittstelle besteht insgesamt 
aus den folgenden Dateien:



* Robot.java
* RobotControl.java
* RobotInstructions.java

Die Fabrik ist von ihren Fertigungsanlagen her so konzipiert, dass jeder Roboter einzeln 
gefertigt wird. Übergeben wird lediglich das gewünschte Roboter-Modell und der Name und 
schon erhält der Kunde den von ihm gewünschten Roboter (also in der Simulation eine Instanz).
Der Unterschied zwischen den angebotenen Modellen liegt in der Ausführung der Befehle aus 
dem Interface RobotInstructions. Während R2D2 Arrays immer aufsteigend sortiert und bei der 
Umwandlung in ein Array den Inhalt durch Kommas trennt (z.B. 1, 2, 3, 4, 5, 6), sortiert C3PO 
Arrays stets absteigend und wandelt deren Inhalt in einen String mit Semikolon als Trennzeichen 
um (z.B. 6; 5; 4; 3; 2; 1). R2D2 soll für die Sortierung der Daten einen selbst implementierten 
SelectionSort-Algorithmus verwenden, C3PO InsertionSort. Die Zusammenstellung des Strings für 
die Rückgabe soll in einer privaten Methode der Roboter- Basisklasse mit Hilfe eines Streams und 
Lambda-Ausdrücken erfolgen.
Programmieren Sie zwei Klassen R2D2 und C3PO, die beide das Interface Robot implementieren. 
Lesen Sie bitte sorgfältig die Dokumentation der Interfaces, damit Sie die beschriebene Semantik 
in Ihrer Implementierung einhalten. Die Seriennummern der R2D2- Modelle bewegen sich im Bereich 
von 0–9999, die der C3PO-Modelle von 10000–19999. Schreiben Sie ferner die in den Interfaces 
referenzierten Klassen für die Ausnahmen. Sorgen Sie dafür, dass die Ausnahmen den Namen des 
Roboters tragen, in dem sie entstanden sind und dass man diesen Namen über die Methode getRobotName() 
wieder auslesen kann.
Auch für die Implementierung der Exceptions kann daher eine gemeinsame Superklasse hilfreich sein.
Entwickeln Sie eine Klasse RobotFactory mit deren Hilfe man Instanzen der beiden Roboter- Typen 
erzeugen kann. Eine Enumeration mit dem Namen RobotType dient dazu, bei der Erzeugung anzugeben, 
ob man einen R2D2- oder einen C3PO-Roboter haben möchte.
Vergessen Sie nicht, dass jeder Roboter eine Seriennummer aus dem jeweiligen Bereich benötigt und 
dass er bei der Erzeugung seinen unveränderlichen Namen bekommt. Verbergen Sie die Implementierung 
der Roboter vor dem Verwender und erlauben Sie nur Zugriff auf die Factory, die Interfaces und 
die Ausnahmen. Wählen Sie entsprechende Pakete gemäß ihrem Schema, um dies zu realisieren.
Zusätzlich zu den beiden produzierten Roboter-Modellen R2D2 und C3PO steht in der Firma noch ein 
alter Nexus-6-Roboter mit dem Namen “Pris“ (Seriennummer 19281982)herum, der leider seit einer 
Begegnung mit einem Blade-Runner irreparabel defekt ist und nicht eingeschaltet werden kann (man kann 
den Schalter zwar drücken, dies hat aber keine Wirkung). Da es nur dieses eine Exemplar gibt, können 
auch keine weiteren Nexus-6- Modelle hergestellt werden. Implementieren Sie daher den Nexus-6-Roboter 
(Klassenname Nexus6) als Singleton. Beachten Sie, dass die speak- und think-Methoden nicht funktionieren 
sollen, sondern grundsätzlich eine Ausnahme Robot"-Illegal"-State"-Exception werfen.
Schreiben Sie automatisierte JUnit-Tests mit denen Sie die korrekte Funktionsweise der Implementierungen 
und der Factory-Klasse überprüfen. Denken Sie daran, auch die Ausnahmen zu testen.
Angenommen, Ihre Firma möchte eine weitere Produktlinie eröffnen und in Zukunft auch noch T1000-Roboter 
herstellen, die natürlich auch das Robot-Interface implementieren: Welche Änderungen müssten Sie an Ihrem 
Projekt durchführen? Sie brauchen keine Implementierung dafür zu erstellen, legen Sie dafür bitte eine 
Textdatei in Ihr Projekt, in der Sie die notwendigen Erweiterungen und evtl. Änderungen kurz erläutern.
* Mit Ihrer Implementierung sollten folgende Begrifflichkeiten abgedeckt sein: 
  * Singleton-Pattern, 
  * Factory-Pattern, 
  * Exceptions, 
  * Interfaces, 
  * abstrakte Klassen, 
  * JUnit- Tests, 
  * Enumerationen, 
  * Sortieralgorithmen, 
  * Streams & Lambdas.
* Achten Sie bei Ihrer Implementierung auf die Konsistenz der Sprache (Englisch/Deutsch).
* Kommentieren Sie Ihre Methoden ausführlich mit Javadoc-Kommentaren, 
  * wie in den Interfaces gezeigt (googlen Sie ggf. nach weiteren Details dafür). 
* Bei der Implementierung von Methoden aus den Interfaces, dürfen Sie mit @see... auf deren Javadocs verweisen und müssen die Dokumentation nicht duplizieren.
* Sie müssen kein UML-Diagramm anfertigen, können dies aber gerne tun.
* Testen Sie Ihre Implementierung möglichst umfangreich. Wir werden es auf jeden Fall tun. !
* Nutzen Sie für die gemeinsame Arbeit an der Implementierung ein Git-Repository und nutzen Sie regelmäßig. 
* Es müssen von allen Team-Mitgliedern jeweils mindestens fünf Commits mit substanziellem Inhalt auf den main-Branch gepusht werden.