# Aufgabe zu Schnittstellen



## JavaIsTheBest (29. Mai 2016)

Hallo,
in der Aufgabe steht folgender Satz.

Definieren Sie Account, ChargedAccount und LimitedAccount mit den aus der Vorlesung bzw. früheren Aufgaben
bekannten *Eigenschaften *als Schnittstellen!


Jetzt sind Eigenschaften aber Attribute und keine Methoden. Ist die Aufgabe falsch formuliert oder wie soll ich das verstehen?

Und ich verstehe nicht, was die Methode "booking()" machen soll bzw. warum diese da ist?


----------



## mrBrown (29. Mai 2016)

Es sollen nicht die Attribute selbst, sondern die Methoden für diese deklariert werden. Ist vllt etwas unschön formuliert...

#booking soll einen Betrag entgegennehmen, und diese zum Kontostand addieren. So müssen die Unterklassen nicht mehr #deposit und #withdraw implementieren, sondern das unkomplexere #booking


----------



## JavaIsTheBest (30. Mai 2016)

1) Kann man folgendes sagen?

Ein ChargedLimitedAccount ist ein ChargedAccount oder LimitedAccount.
Ein ChargedAccount oder LimitedAccount ist ein ChargedLimitedAccount.

2) Müssen die Objektvariablen in der Klasse AccountImpl unbedngt final sein oder reicht auch private aus?

3) Warum wird die Variable private final int number deklariert aber nicht im Konstruktor aufgerufen?

4) Warum ist das möglich, obwohl der Konstruktor nur ein Argument als Parameter hat?


```
public AccountImpl (String h) {
this(h, 0);
}
```


----------



## mrBrown (30. Mai 2016)

JavaIsTheBest hat gesagt.:


> 1) Kann man folgendes sagen?
> 
> Ein ChargedLimitedAccount ist ein ChargedAccount oder LimitedAccount.
> Ein ChargedAccount oder LimitedAccount ist ein ChargedLimitedAccount.


ChargedLimitedAccount ist ChargedAccount *und* LimitedAccount 
Die Implementationen von ChargedAccount oder LimitedAccount *können* ChargedLimitedAccount sein, müssen aber nicht. Die Interfaces ChargedAccount und LimitedAccount sind kein ChargedLimitedAccount.



JavaIsTheBest hat gesagt.:


> 2) Müssen die Objektvariablen in der Klasse AccountImpl unbedngt final sein oder reicht auch private aus?



final bedeutet etwas anderes als private. privat heißt nicht sichtbar, final nicht änderbar.
Sinnvoll ist hier final, da sich zB die Kontonummer niemals ändern darf.



JavaIsTheBest hat gesagt.:


> 3) Warum wird die Variable private final int number deklariert aber nicht im Konstruktor aufgerufen?



Nummer wird direkt initialisiert, muss also nicht mehr im Konstruktor gesetzt werden. Bei final ginge auch nur entweder so, oder im Konstruktor. Hier sorgt das für fortlaufende Nummern.



JavaIsTheBest hat gesagt.:


> 4) Warum ist das möglich, obwohl der Konstruktor nur ein Argument als Parameter hat?
> 
> 
> ```
> ...



this(...) ruft einen anderen Konstruktor auf, in diesem Fall AccountImpl(String h, int b). Wie viele Argumente die beiden haben ist egal, es müssen nur bei jedem Aufruf die passenden sein.


----------



## JavaIsTheBest (31. Mai 2016)

1. Das heißt, jedes Mal, wenn ein neues Objekt erzeugt wird, dann wird "number" automatisch um Eins erhöht?

2. In der Klasse ChargedAccountImpl gibt es die Methode charge(int *amount*). Ist amount die Gebühr? Und warum gibt es in der Musterlösung keine Objektvariable _charge_? Das hätte ich mit reingenommen.


----------



## JavaIsTheBest (31. Mai 2016)

3. Wozu sind die zwei Klassen ChargedLimitedAccountImpl1 und ChargedLimitedAccountImpl2 da? Hätte nicht einfach eine Klasse ChargedLimitedAccountImpl gereicht?

4. In der Musterlösung steht in der Klasse LimitedAccountImpl die Methode _public static boolean check (LimitedAccount account, int amount)._
LimitedAccount ist eine Schnittstelle. Ist das erlaubt, dass man als Parametertyp, eine Schnittstelle angibt?

5. Stimmt meine check- Methode soweit? Ich weiß nicht, ob das limit positiv oder negativ betrachtet wird.



Spoiler: check-Methode





```
public static boolean check(LimitedAccount la, int amount){
     if(la.balance()-amount<la.limit()){
       System.out.println("Unzulässige Kontoüberziehung");
       return false;
     }
     return true;
```




6. Die Methoden withdraw und transfer werden in der Klasse LimitedAccountImpl überschrieben. Diese Methoden sind aber nicht in der Klasse AccountImpl implementiert. Kommen die Methoden aus dem Interface Account?


----------



## mrBrown (31. Mai 2016)

JavaIsTheBest hat gesagt.:


> 1. Das heißt, jedes Mal, wenn ein neues Objekt erzeugt wird, dann wird "number" automatisch um Eins erhöht?



Jein, number wird auf nextNumber gesetzt, und nextNumber direkt incrementiert.
number ist Instanzvariable, nextNumber Klassenvariable.




JavaIsTheBest hat gesagt.:


> 2. In der Klasse ChargedAccountImpl gibt es die Methode charge(int *amount*). Ist amount die Gebühr? Und warum gibt es in der Musterlösung keine Objektvariable _charge_? Das hätte ich mit reingenommen.



Leider ist nirgendwo beschrieben, was genau #charge machen soll, bzw aufgerufen werden soll. Mit vernünftigem JavaDoc wäre das klarer gewesen...
Wofür hättest du denn die Variable benutzt?




JavaIsTheBest hat gesagt.:


> 3. Wozu sind die zwei Klassen ChargedLimitedAccountImpl1 und ChargedLimitedAccountImpl2 da? Hätte nicht einfach eine Klasse ChargedLimitedAccountImpl gereicht?



WO sind sie denn da? Vermutlich sind das zwei mögliche Implementationen des Interfaces, man kann logischerweise nicht beide in einer Klasse unterbringen, brauchen tut man aber nur eine.




JavaIsTheBest hat gesagt.:


> 4. In der Musterlösung steht in der Klasse LimitedAccountImpl die Methode _public static boolean check (LimitedAccount account, int amount)._
> LimitedAccount ist eine Schnittstelle. Ist das erlaubt, dass man als Parametertyp, eine Schnittstelle angibt?


Es ist nicht nur erlaubt, sondern erwünscht, Interfaces und nicht Klassen bei der Deklaration zu benutzen 
So klappt die Methode für alle LimitedAccounts, wäre da eine Klasse angegeben, klappt es nur für diese eine Klasse, für alle anderen Implementation, für die es nützlich wäre, klappt es aber nicht.



JavaIsTheBest hat gesagt.:


> 5. Stimmt meine check- Methode soweit? Ich weiß nicht, ob das limit positiv oder negativ betrachtet wird.



Wenn limit das untere Limit angibt, stimmt deine Methode so.
Wie das gemeint ist, steht sicherlich irgendwo erklärt (und gehört ins JavaDoc)



JavaIsTheBest hat gesagt.:


> 6. Die Methoden withdraw und transfer werden in der Klasse LimitedAccountImpl überschrieben. Diese Methoden sind aber nicht in der Klasse AccountImpl implementiert. Kommen die Methoden aus dem Interface Account?



Ja, implementiert sind sie auch schon in AbstractAccount.
Warum werden die in LimitedAccountImpl überschrieben?


----------



## JavaIsTheBest (31. Mai 2016)

ZU 2)


> Wofür hättest du denn die Variable benutzt?



Die Variable charge hätte ich als Gebühr benutzt. Also, dass die Gebühr, 10 oder z.B. 20 Cent beträgt.

Zu 3) Im Anhang habe ich die zwei Klassen, ChargedLimitedAccountImpl1 und ChargedLimitedAccountImpl2 markiert. 


> ...man kann logischerweise nicht beide in einer Klasse unterbringen, brauchen tut man aber nur eine.



Warum ist das so? Das verstehe ich noch nicht ganz, warum man zwei Klassen benötigt.

Zu 6) 
withdraw() und transfer() werden überschrieben um unzulässige Überziehungen zu unterbinden.


----------



## mrBrown (31. Mai 2016)

JavaIsTheBest hat gesagt.:


> ZU 2)
> Die Variable charge hätte ich als Gebühr benutzt. Also, dass die Gebühr, 10 oder z.B. 20 Cent beträgt.



Die Methode stammt sowieso aus dem Interface, da kann es das Feld nicht geben, das gäbe es dann höchstens in der Implementation. Allerdings auch nur wenn es nötig ist, uU ist die Gebühr ja auch ein Prozentsatz, da hätte man dann dafür ein Feld, und nicht mehr für die Gebühr an sich.



JavaIsTheBest hat gesagt.:


> Zu 3) Im Anhang habe ich die zwei Klassen, ChargedLimitedAccountImpl1 und ChargedLimitedAccountImpl2 markiert.
> 
> Warum ist das so? Das verstehe ich noch nicht ganz, warum man zwei Klassen benötigt.



Man kann die Klasse auf 2 Arten implementieren, und hier ist einfach nur ein Beispiel für beide Varianten gegeben. Brauchen tut man nur eine, mehrere zur Auswahl haben ist aber selten schlecht


----------



## JavaIsTheBest (31. Mai 2016)

mrBrown hat gesagt.:


> Man kann die Klasse auf 2 Arten implementieren, und hier ist einfach nur ein Beispiel für beide Varianten gegeben. Brauchen tut man nur eine, mehrere zur Auswahl haben ist aber selten schlecht



Achso, jetzt verstehe ich es. Mehrfachvererbung ist  in Java nicht möglich. Deswegen gibt es eimal die Variante, wo von ChargedAccountImpl oder LimitedAccountImpl geerbt wird.


----------



## mrBrown (31. Mai 2016)

JavaIsTheBest hat gesagt.:


> Achso, jetzt verstehe ich es. Mehrfachvererbung ist  in Java nicht möglich. Deswegen gibt es eimal die Variante, wo von ChargedAccountImpl oder LimitedAccountImpl geerbt wird.



Genau


----------

