HashMap

[Börmt-die-Buse]

Guten Tag

ich versuche gerade HashMap mir wieder selber verständlicher zu machen. Dazu habe ich folgende aufgabenstellung.

a),b) sind meiner meinung nach richtig. nur bei aufgabenstellung c) bin ich mir nicht sicher ob das stimmt was ich dort schreibe. ich würde auch noch gerne wissen warum ich schreiben muss (HashMap<Integer, Artikel>). Wieso reicht für "Integer" kein "int".

Müssen abgeleitete Methoden immer den selben Sichtbarkeitstatus haben wie die Oberklassenmethoden?

Danke schonmal im Vorraus

Geldbeträge brauchen nicht gerundet zu werden.
a) Schreiben Sie für eine Kassen-Software eine Klasse Artikel, die als Attribute eine ganzzahlige Artikelnummer, den Nettopreis in Cent und einen beschreibenden String hat.
Fügen Sie einen Konstruktor hinzu, der die Attribute mit als Parameter übergebenen Werten belegt.
Fügen Sie die Methode getPreis hinzu. Diese gibt den Nettopreis in Cent für diesen Artikel zurück, es sei denn die boolean-Konstante Aktionen.MINUS_ZWANZIG hat den Wert true. In diesem Fall wird der um 20% reduzierte Cent-Betrag zurückgegeben. (Die Klasse Aktionen muss nicht definiert werden.)
Fügen Sie eine Methode getMwstBetrag hinzu. Diese gibt den Mehrwertsteuerbetrag für diesen Artikel in Cent zurück. Der gewöhnliche Mehrwertsteuersatz ist 19%.

b) In den folgenden Aufgaben können Sie davon ausgehen, dass für jedes Attribut von Artikel Getter und Setter existieren. Schreiben Sie eine von Artikel abgeleitete Klasse Tiernahrung, die die ererbten Methoden getPreis und getMwstBetrag wie folgt modifiziert: Der Wert von Aktionen.MINUS_ZWANZIG hat keinen Einfluss auf getPreis, der Mehrwertsteuersatz ist hier 7%.

c) Schreiben Sie eine main-Methode, die eine HashMap namens lager anlegt. Diese soll so parametrisiert werden, dass sie den Zugriff auf einen Artikel über dessen Artikelnummer erlaubt. Erzeugen Sie einen „Hundekuchen“ mit Artikelnummer 4711, Nettopreis 200 Cent, und fügen Sie ihn in lager ein. Ermitteln Sie mit Hilfe von lager den Preis des Artikels mit der Artikelnummer 12345 und geben Sie diesen aus.

package Comparable_üben;

import java.util.HashMap;

public class Artikel {
    int artikelnummer = 0;
    int nettopreis = 0;
    String name="";
    
    Artikel(int artikelnummer, int nettopreis, String name){
        this.artikelnummer = artikelnummer;
        this.nettopreis = nettopreis;
        this.name = name;
    }
    
    public int getPreis(){
        if(Aktionen.MINUS_ZWANIG == true){
            return ( nettopreis *80)/100;
        }
        return nettopreis;
    }
    public int getMwstBetrag(){
        return(nettopreis * 19)/100;
    }
}

class Tiernahrung extends Artikel{

    Tiernahrung(int artikelnummer, int nettopreis, String name) {
        super(artikelnummer, nettopreis, name);
    }

    public int getPreis(){
        return nettopreis;
    }
    
    public int getMwstBetrag(){
        return (nettopreis * 7)/100;
    }
    
    public static void main(String[] args) {
        Artikel a;
        int n;
        HashMap<Integer,Artikel> lager = new HashMap();
        Artikel hundekuchen = new Artikel (4711,200,"Hundekuchen");
        lager.put(4711, hundekuchen);
         a = lager.get(12345);
         n = a.getPreis();
         
    }
}

 

[njans]

Ich habe mir nur die main angeguckt:
Das sieht alles korrekt aus, da du eine Map<Integer, Artikel> hast, wie gefordert.
Du legst einen neuen Artikel in die Map mit dem Key 4711 und anschließend holst du dir einen anderen Artikel mit der Artikelnummer 12345 und speicherst seinen Preis. Du vergisst aber die Ausgabe

public static void main(String[] args) {
        HashMap<Integer,Artikel> lager = new HashMap();
        Artikel hundekuchen = new Artikel (4711,200,"Hundekuchen"); 
        lager.put(4711, hundekuchen);
        int preis = lager.get(12345).getPreis();  // Das kann man so auch kürzer schreiben ;)  
    }

 

[Börmt-die-Buse]

Dann noch zu meinen anderen 2 Fragen

Wieso reicht bei HashMap<Integer,Artikel> nicht HashMap<int,Artikel>.
Müssen abgeleitete Methoden immer den selben Sichtbarkeitstatus haben wie die Oberklassenmethoden?

 

[Kevin94]

Integer musst du Aufgrund der technischen Umsetzung von Generics verwenden(Type Erasure), die nur Klassen als Typparameter erlaubt, primitive Datentypen sind deshalb nicht möglich.

Die Sichtbarkeit einer überschreibenden Methode muss nicht zwangsläufig die selbe sein wie die der Oberklasse, sie darf die Sichtbarkeit dieser erweitern, d.h. wenn die Methode in der Oberklasse z.B. protected-Sichtbarkeit hat, kannst du sie in einer abgeleiteten Klasse auch als public definieren aber nicht als package-private (als private schon gar nicht).

 

[njans]

Wieso reicht bei HashMap<Integer,Artikel> nicht HashMap<int,Artikel>.

Weil du dort Objekte angibst und int, double, char, float, etc sind keine Objekte sondern Literale.

Müssen abgeleitete Methoden immer den selben Sichtbarkeitstatus haben wie die Oberklassenmethoden?

Die Sichtbarkeit muss mindestens gleich groß sein.

 

[Landei]

Hinzuzufügen wäre, dass Arrays auch zu den Objekten gehören, [c]HashMap<String,int[]>[/c] also erlaubt wäre.

 

[faetzminator]

Integer musst du Aufgrund der technischen Umsetzung von Generics verwenden(Type Erasure), die nur Klassen als Typparameter erlaubt, primitive Datentypen sind deshalb nicht möglich.

Und auch vor Generics war es nicht möglich
@TO: Schau dir z.B. [c]System.out.println()[/c] an. Da gibts wohl ca. 10 Methoden. Eine für [c]Object[/c], dann pro primitivem Datentypen eine. Das gäb ein riesiges Gebastel in der Map

 

[Kevin94]

Vor den Generics war es aber offensichtlich, dass primitive Datentypen nicht gehen, weil in den Signaturen eben Object stand. Mit Generics sollte sich am Bytecode der Klassen fast nichts geändert haben, in den JavaDocs steht aber anstatt Object der generische Typparameter, und das das eine Klasse sein muss ist eben nicht mehr offensichtlich.

 

[faetzminator]

Deine Aussage ist also, dass wenn du einen Parameter Object hast, ist für dich klar, dass keine primitiven Datentypen eingefügt werden kann (inzwischen natürlich schon, mit Autoboxing). Wenn dieser Parameter aber nicht Object, sondern ein anderer beliebiger nicht-primitiver Typ ist, ist dir das nicht klar? Lass ich einfach mal so stehen... :autsch:

 

[Kevin94]

Meine Aussage ist, dass es, auf JavaDoc-Ebene betrachtet, nicht offensichtlich ist warum ein generischer Parameter kein primitiver Datentyp sein kann (gibts in anderen Sprachen ja), wenn man sich mit Generics tiefer beschäftigt hat, ist es dann logisch. Bei einer Methode mit Object in der Signatur scheint mir das (ohne Autoboxing) offensichtlich.