Vererbung?!

[unknownUser]

Hallo zusammen, ich möchte neben den Klassen eine Klasse implementieren, die jeweils die getPrice-Methoden von Salad und Publication addiert. Wie kann ich jeweils auf die erstellten Objekte (Salad und Publication) zugreifen? Bei einer Vererbung müsste ich ja theorethisch alles von der abstrakten Klasse ShoppingCardEntry erben? Vielen Dank für jegliche Hilfe

 

[Oneixee5]

Die Addition wäre imho eine Aufgabe von ShoppingCard. ShoppingCard sollte nach meinem Verständnis die ShoppingCardEntry's kennen. Somit kann ShoppingCard die Preise abholen und addieren.

 

[unknownUser]

Erstmal, vielen Dank für deine Antwort

Ja, das wäre auch meine Idee gewesen. Ich hätte jetzt spontan gedacht, einfach das die Klasse ShoppingCard den Interface Buyable erbt. Jedoch weiß ich nicht ganz wie ich dies realisieren soll. Das Problem ist, wenn jedes Mal ein Objekt von den Childs erzeugt wird möchte ich jeweils die Preise von allen erzeugten Objekten addieren. Bei der Idee mit der Erstellung einer neuen Klasse, die das Interface erbt kriege ich das Problem mit dem Rückgabewert nicht gelöst?

Die Addition wäre imho eine Aufgabe von ShoppingCard. ShoppingCard sollte nach meinem Verständnis die ShoppingCardEntry's kennen. Somit kann ShoppingCard die Preise abholen und addieren.

 

[fhoffmann]

Du solltest das Problem nicht über Vererbung ("is a") sondern über Komposition ("has a") lösen.
Deine Klasse ShoppingCard bekommt also eine Liste von ShoppingCardEntry. Um den Gesamtpreis zu berechnen, geht sie dann die Liste durch und addiert die Einzelpreise.

 

[Oneixee5]

    public static final class ShoppingCard {

        private final List<ShoppingCardEntry> shoppingCardEntrys = new ArrayList<>();

        public void add(final ShoppingCardEntry shoppingCardEntry) {
            this.shoppingCardEntrys.add(shoppingCardEntry);
        }

        public int getTotal() {
            return this.shoppingCardEntrys.stream().collect(Collectors.summingInt(ShoppingCardEntry::getPrice));
        }

    }

    public static final class ShoppingCardEntry {

        private final int price;

        public ShoppingCardEntry(final int price) {
            this.price = price;
        }

        public int getPrice() {
            return this.price;
        }

    }

    public static void main(final String[] args) throws Exception {

        final ShoppingCard shoppingCard = new ShoppingCard();

        for (int i = 0; i < 20; i++) {
            shoppingCard.add(new ShoppingCardEntry(i));
        }

        System.out.println(shoppingCard.getTotal());
    }

 

[White_Fox]

Ich hätte jetzt spontan gedacht, einfach das die Klasse ShoppingCard den Interface Buyable erbt. Jedoch weiß ich nicht ganz wie ich dies realisieren soll.

Versuche, den Code mal zu lesen. Und zwar im Sinne davon, daß Bezeichner eine Bedeutung haben. Wenn du einen deutschen Text liest, dann erfaßt du (hoffentlich) dessen Sinn. Lerne, Quellcodetext genauso zu lesen, denn dann lösen sich viele Fragen in Wohlgefallen auf.

Und dann überlege mal: ist ein ShoppingCard (Ich vermute mal einen Schreibfehler, es soll wohl eher ein ShoppingCardt sein) "Byable"? Auch wenn man einen Euro in den Wagen steckt, gilt es doch allgemein als Frevel, ihn nach dem Einkauf mitzunehmen.

PS:
Und wenn du Quellcode sinnerfassend lesen kannst (ich meine das übrigens tatsächlich nicht ironisch oder so, ich schätze mal 80% aller Anfängerfragen hängen an dieser Stelle und würde sich in Wohlgefallen auflösen, wenn sie Quellcode als sinnvollen Text lesen würden), versuche künftig, auch sinnvollen Quellcode zu schreiben – richtig guten Quellcode zu schreiben ist eine Kunst, hilft dir aber selbst am meisten.

 

[mihe7]

Auch wenn man einen Euro in den Wagen steckt, gilt es doch allgemein als Frevel, ihn nach dem Einkauf mitzunehmen.

Da kann man es mit einem Zwanziger zu einem stattlichen Fuhrpark bringen

 

[Mart]

Auch wenn man einen Euro in den Wagen steckt, gilt es doch allgemein als Frevel, ihn nach dem Einkauf mitzunehmen.

grill bei ikea für 1 euro

 

[fhoffmann]

Und dann überlege mal: ist ein ShoppingCard (...) "Byable"? Auch wenn man einen Euro in den Wagen steckt, gilt es doch allgemein als Frevel, ihn nach dem Einkauf mitzunehmen.

Möglicherweise hat aber auch nur das Interface "Byable" einen unglücklichen Namen (und man sollte diesen Namen ändern). Denn ShoppingCard (oder ShopingCart) kann durchaus die Methode getPrice() (im Beispiel von @Oneixee5 getTotal() genannt) implementieren.

 

[fhoffmann]

Was mir am ursprünglichen Modell nicht gefällt, ist, dass die Klasse ShoppingCardEntry ein protected Member amonut (vom Typ int) hat. Sollen nun alle erbenden Klassen (und es wird viele erbende Klassen geben) ihren eigenen Preis mit der Menge der Produkte multiplizieren? Das kann doch nur schief gehen!

 

[D.gigi]

Hallo zusammen ich wollte auch mal mich an die UML Datei heranwagen, nun versteh ich das interface Buyable nicht so ganz und wo wird Buyable nun in der klasse ShoppingCartEntry implementiert wäre super wenn mir da jemand einen ansatz geben könnte LG.

 

[mihe7]

nun versteh ich das interface Buyable nicht so ganz

Das Interface spezifiziert eine Methode namens getPrice(), die ein float liefert. Jede Klasse, die dieses Interface implementiert, bietet demnach diese Methode an (bzw. muss diese Methode anbieten).

wo wird Buyable nun in der klasse ShoppingCartEntry implementiert

Verstehe die Frage nicht, daher einfach mal ein kleines Beispiel:

class FreeItem implements Buyable {
    @Override
    public float getPrice() {
        return 0f;
    }
}

Oder meinst Du im UML? Das wird durch die gestrichelte Generalisierung angezeigt, bei einer Vererbung wäre die Linie durchgezogen.

 

[X5-599]

Vermutlich ist gemeint, dass im UML die Klasse "ShoppingCardEntry" das Interface "Buyable" implementiert aber die benötigte Methode "getPrice" nicht in dessen Methodenliste auftaucht. Was natürlich ein Fehler wäre. Beim genauen hinsehen allerdings fällt auf, dass "ShoppingCardEntry" in Italics geschrieben ist. In UML ist das eine Möglichkeit um abstrakte Klassen darzustellen.

Lange Rede; kurzer Sinn: Die Klasse "ShoppingCardEntry" implementiert das Interface, braucht aber die darin vereinbarte Methode nicht anzubieten, da sie abstrakt ist. Somit reicht es, wenn die davon erbenden Klassen jeweils die Methode anbieten.

Anmerkung: Natürlich könnten diese erbenden Klassen auch ihrerseits abstrakt sein. Dann müssten sie die Methode ebenfalls nicht selbst anbieten. So kann man diese Verantwortung immer weiter "nach hinten" schieben. Bis zu dem Punkt an dem eine instanziierbare (nicht abstrakte) Klasse definiert wird. Die muss dann letztendlich die Interface Methode anbieten.

Anmerkung zur Anmerkung: Das heißt natürlich nicht, dass nur "nicht abstrakte" Klassen die Interface Methoden bereit stellen dürfen. In der fiktiven Vererbung, die ich angedeutet habe (wo abstrakte Klasse von abstrakter Klasse erbt etc), ist es durchaus erlaubt, dass eine der abstrakten Klassen diese Interface Methode selbst anbietet und somit eine von dieser abstrakten Klasse erbende instanziierbare Klasse das nun nicht mehr tun muss (obwohl sie das natürlich immer noch könnte).

 

[mihe7]

Was natürlich ein Fehler wäre.

Das würde ich so nicht sagen, da in UML "nicht dargestellt" einfach nur "nicht dargestellt" heißt.

 

[Mart]

dass "ShoppingCardEntry" in Italics geschrieben ist. In UML ist das eine Möglichkeit um abstrakte Klassen darzustellen.

also wenn du es nicht gesagt hättest hätte ich es nicht gesehen.. da muss man wirklich mit ner lupe ran gehen

 

[X5-599]

Das würde ich so nicht sagen, da in UML "nicht dargestellt" einfach nur "nicht dargestellt" heißt.

Das kann natürlich sein. Ich bin auch der erste, der zugibt mit UML schon immer auf Kriegsfuß gestanden zu sein. Ich schieb' das auf die Informatiker Schule, die uns zuerst das Programmieren beigebracht hat und erst viel später Software Engineering. UML war mir da immer "zu abstrakt".

also wenn du es nicht gesagt hättest hätte ich es nicht gesehen.. da muss man wirklich mit ner lupe ran gehen

Gibt wohl auch noch andere Möglichkeiten Klassen als abstrakt zu kennzeichnen. "Klassenname {abstract}" oder "Klassenname <<abstract>>". Wobei sich die Leute da wohl auch nicht einig sind was nun erlaubt ist und was nicht.
In Anlehnung an meine Antwort an Mihe7 von oben: Bei so einem Thema wie UML wundert mich das auch nicht wirklich.