Designfrage Vererbung ja oder nein

[gorgonsel]

Hallo,

ich habe eine Klasse Produkt, die mit der Zeit gewachsen ist und einige Methode haben etliche if Anweisungen, die nach Produtktyp unterscheiden. Also habe ich angefangen, alles was allgemein gültig ist, in eine Basisklasse Produkt zu schreiben und Subklassen zu bilden (ca. 30 Stück). Jetzt stellt sich folgende Frage bei der Methode setRabatt: Macht hier Vererbung wirklich Sinn.

Die Höhe des Rabatts hängt nicht nur vom Produkt ab, sondern auch vom angemeldeten Benutzer. So würde sich also die Abfrage auf den Benutzer in den Subklassen immer wiederholen. Gibt es einen eleganteren Weg, das zu lösen, oder sollte ich diese Methode lieber in der Klasse Produkt so stehen lassen und nur da Vererbung nutzen, wo die Funktionalität nur vom Produkttyp abhängt?

Frank

// Ohne Vererbung

class Produkt {
	void setRabatt() {
		if (this.getAngebot().getUser().isAdmin() {
			// Erlaube bis 100% Rabatt
		}
		else {
			if (this.getProduktbereich == B1) {
				// Erlaube bis 20% Rabatt
			}
			else if (this.getProduktbereich == B2) {
				// Erlaube bis 30% Rabatt
			}
			else {
				// Erlaube bis 10% Rabatt
			}
		}
	)
}



// Mit Vererbung
class Produkt {
	void setRabatt() {
		if (this.getAngebot().getUser().isAdmin() {
			// Erlaube bis 100% Rabatt
		}
		else {
			// Erlaube bis 10% Rabatt
		}
	)
)

class Produkt_B1 extends Produkt {
	void setRabatt() {
		if (this.getAngebot().getUser().isAdmin() {
			// Erlaube bis 100% Rabatt
		}
		else {
			// Erlaube bis 20% Rabatt
		}
	)
}

class Produkt_B2 extends Produkt {
	void setRabatt() {
		if (this.getAngebot().getUser().isAdmin() {
			// Erlaube bis 100% Rabatt
		}
		else {
			// Erlaube bis 30% Rabatt
		}
	)
}

 

[Stewe]

so funktioniert vererbung

// Mit Vererbung
class Produkt {
    void setRabatt() {
        if (this.getAngebot().getUser().isAdmin() {
            // Erlaube bis 100% Rabatt
        }
        else {
            getProduktRabatt();
        }
    )


protected double getproduktRabatt() {
  return 0.1;
}

)
 
class Produkt_B1 extends Produkt {
  protected double getproduktRabatt() {
    return 0.2;
  }
}
 
class Produkt_B2 extends Produkt {
  protected double getproduktRabatt() {
    return 0.3;
  }
}

 

[Michael...]

Die Höhe des Rabatts hängt nicht nur vom Produkt ab

Ein Rabatt hängt überhaupt nicht vom Produkt ab. Er wird eventuell für spezielle Produkte, spezielle Kunden oder allgemein gewährt.

So würde sich also die Abfrage auf den Benutzer in den Subklassen immer wiederholen. Gibt es einen eleganteren Weg, das zu lösen, oder sollte ich diese Methode lieber in der Klasse Produkt so stehen lassen und nur da Vererbung nutzen, wo die Funktionalität nur vom Produkttyp abhängt?

Weder noch. Ich würde sagen im Gegesatz zum Preis oder einer UVP ist ein Rabatt keine Eigenschaft eines Produktes, sondern gehört eher in den Kontext eines Verkaufsprozesses. Daher würde ich den Rabatt zu einem Produkt oder einer Produktgruppe eher in einer separaten Liste/Map pflegen.

 

[FArt]

Nein.
Decorator ? Wikipedia

 

[Andi_CH]

Die Tatsache dass jedes Produkt einen Rabatt hat genügt, dass alle Features welche Rabatt betreffen auch im Produkt angesiedelt sind.

Im allgemeinen gesagt:

Viele if's lassen sich sehr elegant lösen. (Die Methode setRabat im obigen Beispiel ist absolut überflüssig)

In der Vaterklasse hat es eine abstrakte Methode getRabat welche ja überschrieben werden muss und damit kannst du jedes Produkt nach seinem Rabat fragen - das Produkt selbst kann es natürlich auch.

Wenn du zwingend setRabat haben willst und das wirklich ohne Parameter funktionieren soll, sieht es so aus

	abstract class Produkt {
		protected double rabatt;
		abstract void setRabatt();
		double getProduktRabatt() { return rabatt; }
	}

	class Produkt_B1 extends Produkt {
		@Override
		void setRabatt() {
			rabatt = 0.2;
		}
	}

	class Produkt_B2 extends Produkt {
		@Override
		void setRabatt() {
			rabatt = 0.3;
		}
	}

 

[gorgonsel]

Sorry,

ich hatte wirklich vergessen, den Parameter reinzuschreiben bei der set-Methode.
Die Methode bekommt von der Oberfläche einen Rabatt und soll je nach Produkt und angemeldetem User
den Rabatt korrigieren, also z.B. auf den erlaubten Max-Wert setzen, falls die Eingabe höher ist.
Würde das nur vom Produkt abhängen, ist Vererbung prima. Mir geht es um das Problem, dass ich die Verschachtelung mit der Abfrage nach dem User auch in jeder abgeleiteten Klasse noch ein mal muss, sich dieser Code also immer wieder wiederholt, da für jedes Produkt gleich.

 

[Andi_CH]

Es ist ganz einfach - wenn der Code in einer Funktion für alle Produkte identisch ist, kommt er in die Vaterklasse.
Wenn nicht kommt in die Vaterklasse nur der Funktionsprotoyp (die abstrakte Deklaration) und die Implementation steht in jedem Produkt.

 

[gorgonsel]

Hallo,

Es ist ganz einfach - wenn der Code in einer Funktion für alle Produkte identisch ist, kommt er in die Vaterklasse.
Wenn nicht kommt in die Vaterklasse nur der Funktionsprotoyp (die abstrakte Deklaration) und die Implementation steht in jedem Produkt.

das ist soweit schon klar, mit geht es darum, daß der Code aber nicht nur vom Produkttyp (das was ich in den Subklassen implementiere) abhängt, sondern auch noch vom User, der angemeldet ist. In der Methode setRabatt ist also der Teil "wenn User = Admin, dann erlaube 100%", für alle Produkte gleich, könnte also in die Vaterklasse, der zweite Teil der Methode aber nur vom Produkttyp. Diese beiden Dinge kann ich nicht auseinanderreißen. Damit muss ich in jeder Subklasse wieder die Prüfung nach dem User einbauen und das ist sehr unschön.

 

[ThreadPool]

Dann lager die ganze Rabattgeschichte doch einfach aus, eine spontane grobe Idee wäre sowas wie einen Rabattrechner einzuführen, dann eine passende Factory dazu die du mit Produkttyp und User konfigurieren kannst und dann vll. noch ein Interface das eine Methode berechneRabatt hat welche die "rabattierbaren" Produkte implementieren und dort instanziierst du dann mit der Factory, dem User und Produkttyp als Argument einen passenden Rabattrechner (die kannst du auch cachen in der Factory) und lässt dir den Rabatt ausgeben.

 

[gorgonsel]

Danke an alle, ich habe jetzt schonmal 3 Lösungsansätze, die alle besser sind als der bisherige, muss mich nur noch entscheiden...