[OOP] Frage zu Methode-Namen / Funktionsweise

[maxmax]

Hallo,

ich programmiere eine kleine Shop-Simulation mit folgende Situation:

Ein Kunde kann ein Produkt von einem bestimmen Verkäufer kaufen

Ich frage mich nun, welche der 3 Klassen (Kunde, Verkäufer, Produkt) ich eine "buy"-Methode verpassen soll. Ich denke am ehesten dem Kunden, also kunde.buy(produkt,verkäufer).

Dann stellt sich mir aber die Frage, wie die buy-Methode des Kunden aussehen soll?

class Kunde{
void buy(Produkt produkt, Verkaeufer verkaufer)
      verkaufer.sell(produkt); // finde ich irgendwie komisch, da der Kunde dem Verkäufer ja nicht befehlen kann ein Produkt zu verkaufen.
}

Hat mir jemand da ein Tipp, wie man so etwas am besten löst?
Danke.

 

[XHelp]

Was ist denn die Definition von "verkaufen"?
Was soll da genau passieren?

 

[maxmax]

Kunde und Verkäufer haben beide das Attribut Guthaben.
Bei einem Kauf/Verkauf wird dem Verkäufer der Preis des Produktes gutgeschrieben und dem Kunden abgezogen.
Gleichzeitig wird dem Verläufer das Produkt aus seiner Liste gelöscht.

 

[XHelp]

naja, du kannst ja vorher

if (verkaeufer.canSell(produkt)) {
...

Machen, wenn es dadurch besser aussieht 🙂
Je nach dem wie du es ins Absurde treiben willst. Aber generell ist das ja schon richtig: ich gehe zum Verkäufer und sage: Verkauf mir mal 5 Brötchen.

 

[maxmax]

ok, danke dir. Dann war ich nicht ganz auf dem Holzweg 😉

 

[maki]

Fall es flexibler sein soll, bieten sich sog. "specifications" an: DDD: The Specification Pattern - Jak Charlton - Insane World - Devlicio.us - Just the Tasty Bits
Das Beispiel ist zwar C#, tut dem ganzen aber keinen Abbruch.

 

[ice-breaker]

Ehrlich gesagt hätte ich die buy-Methode zum Verkäufer gemacht. Natürlich macht es auch Sinn, dass man sagt der Kunde kauft von einem Verkäufer (Verkäufer als Parameter).
Aber logischer fände ich persönlich, vom Verkäufer, kaufe ich eine Limonade (Verkäufer.buy(Kunde, Produkt)).
Aber ich denke mal, das kann man sehen wie man will.

 

[gman]

Also wenn schon, dann:

Verkaeufer.sell(Kunde, Produkt);

Hängt halt davon ab, von welchem Standpunkt man den Vorgang betrachtet. Da man die Software wohl eher als
Verkäufer/Geschäft/Firma erstellt, ist die Sicht das der Verkäufer etwas einem Kunden verkauft "besser".

 

[Marco13]

Fall es flexibler sein soll, bieten sich sog. "specifications" an

Ich wußte ja, dass man, wenn man es drauf anlegt, alles mögliche als "Pattern" bezeichnen kann...

We'll now learn about the Setter-Pattern. This pattern is quite useful when an object has properties that may be modified from the outside. It is widely used in many scientifc applications, and has a widespread acceptance in computer science. See the list of references [1,3,6,17,33,45,66,93,122] for more information. The pattern consists of introducing a method that has the prefix "set", and which modifies a value:

class SomeClass
{
    int value;
    [b]void setValue(int v) { value = v; }[/b]
}

Listing 1: Classical application of the Setter-Pattern
...
Read the next sections of this Design Pattern Tutorial:
- The Getter-Pattern
- The Isser-Pattern
- The Hasser-Pattern
....


In wie vielen Bibliotheken das schon als "Predicate", "Condition" oder "UnaryBooleanFunction" drin steckt ... :reflect:


Aber zum Thema: Ich denke, das hängt davon ab, wer die aktive Rolle übernehmen soll. Wenn man einen Staubsaugerverkäufer und einen Haustürkunden modelliert, wäre es wohl seller.sell(product, customer), aber beim Einkauf in einem Warenhaus eher customer.buy(product, seller). Man könnte aber auch überlegen, das ganze irgendwie ... neutraler oder abstraker zu beschreiben, ganz spontan aus dem Bauch raus

interface Entity
{
    Transaction initiateTransaction(Product product, Entity other);
    boolean agreesTo(Transaction t);
}
class Seller implements Entity { ... }
class Buyer implements Entity { ... }

class Transaction
{
    Entity buyer;
    Entity seller;
    Product product;
 
    void execute()
    {
        if (buyer.agreesTo(this) && seller.agreesTo(this)) doit();
    }
}

oder so... :bahnhof: Gibt's bestimmt ein Pattern dafür 😀

 

[maki]

Der Verkauf an sich muss ja weder im Verkäufer Objekt noch im Käufer Objekt passieren, könnte auch in einem eigenen Objekt stattfinden (SellingService zB.) 😉

Meine Bemerkung bez. specifications war auf XHelps Post mit dem "canSell" Beispiel gemünzt, war leider nicht klar dargestellt von mir.
Ob specifications als Pattern durchgehen?
k.A. ehrlich gesagt, aber es gibt ja sowas wie Regeln dafür wann etwas als Pattern bezeichnet wird oder nicht.
Jedenfalls sind sie sehr nützlich wenn Validierungen von mehreren Objekten abhängig sind.
Im Endeffekt laufen die meisten Pattern auf Polymorphy hinaus, aber wäre ja langweilig dann nur noch durchzunummerieren 😀