OOP. Objekte auswählen

Question

Ich bin ein relativer Neuling, der in OOP-Begriffen denkt, und habe meinen 'Bauchgefühl' noch nicht gefunden, was den richtigen Weg betrifft. Als eine Übung versuche ich herauszufinden, wo Sie die Linie zwischen verschiedenen Arten von Objekten erstellen würden, indem ich die Getränke auf meinem Schreibtisch als Beispiel benutze.

Angenommen, ich erstelle ein Objekt Drink, die in Attribute wie volume und temperature und Methoden wie pour() und drink(), ich bin zu kämpfen, um zu sehen, wo bestimmte Getränke ‚Typen‘ kommen muss.

Sagen, ich habe einen Drink Typen von Tea, Coffee oder Juice, mein erster Instinkt ist die Unterklasse Drink, da sie Attribute und Methoden gemeinsam haben.

Das Problem wird dann sowohl Tea und Coffee Attribute haben wie sugars und milk, aber Juice nicht, während alle drei haben eine variant (Earl Grey, decaff und orange beziehungsweise).

ähnlich Tea und Coffee haben ein addSugar() Verfahren, während die keinen Sinn für ein Juice Objekt machen.

Also bedeutet das, dass die Super-Klasse diese Attribute und Methoden haben sollte, auch wenn sie nicht alle Unterklassen benötigen, oder definiere ich sie in den Unterklassen, speziell für Attribute wie variant, wo Jede Unterklasse hat ihre eigene Liste gültiger Werte?

Aber dann am Ende mit zwei addSugar() Methoden, auf den Tea und Coffee Unterklassen.

Oder vorausgesetzt, dass ich dann am Ende alle Attribute und Methoden auf die Super-Klasse setzen, wie die meisten von mindestens ein paar der Getränke-Typen geteilt werden, frage ich mich, was war der Sinn in Sub-Classing überhaupt?

Ich befürchte, ich versuche nur zu viel zu abstrahieren, aber ich möchte mich nicht in einer Ecke zurückhalten, wenn ich einen neuen Typ hinzufügen möchte, wie Water -mit variant still oder glitzernd-die Straße hinunter.

Answer 1

Ein Teil des Problems besteht darin, dass reale Objekte nicht sauber in einer Hierarchie angeordnet sind. Jedes Objekt hat viele verschiedene Eltern. Ein Glas Saft ist sicherlich ein Getränk, aber es ist auch eine Nahrungsquelle - aber nicht jedes Getränk ist. Es gibt nicht viel Nahrung in einem Glas Wasser. Ebenso gibt es viele Nahrungsquellen, die keine Getränke sind. Aber die meisten Sprachen lassen Sie nur von einer Klasse erben. Eine Tasse Tee ist technisch eine Energiequelle (sie ist heiß, sie enthält Wärmeenergie), aber auch eine Batterie. Haben sie eine gemeinsame Basisklasse?

Und natürlich die Bonusfrage, was soll ich verhindern, dass ich Zucker in meinen Saft trinke, wenn ich will? Physisch ist das möglich. Aber es ist nicht konventionell gemacht. Was möchtest du modellieren?

Schließlich versuchen Sie nicht, "die Welt" zu modellieren. Modellieren Sie stattdessen Ihr Problem. Wie möchten Sie Ihre Anwendung zu Deal mit einer Tasse Tee? Welche Rolle spielt eine Tasse Tee bei Ihrer Bewerbung? Welche der vielen möglichen Eltern ist in Ihrem Fall sinnvoll?

Wenn Ihre Anwendung zwischen "Getränken, denen Sie Zucker hinzufügen können" und "Getränke, die Sie nur konsumieren können" unterscheiden muss, dann hätten Sie wahrscheinlich zwei unterschiedliche Basisklassen. Brauchen Sie sogar die gemeinsame "Getränkeklasse"? Vielleicht, vielleicht nicht. Einer Bar ist es vielleicht egal, dass es ein Getränk ist, dass es trinkbar ist. es ist ein Produkt, das verkauft werden kann, und in einem Fall müssen Sie den Kunden fragen, ob er Zucker darin haben möchte, und in dem anderen Fall ist das nicht notwendig. Aber die Basisklasse "Trinken" ist möglicherweise nicht notwendig.

Aber für die Person, die das Getränk trinkt, möchten Sie wahrscheinlich eine Basisklasse "Trinken" mit einer Consume() -Methode haben, denn das ist der wichtige Aspekt davon.

Schließlich, denken Sie daran, dass Ihr Ziel ist, ein funktionierendes Programm zu schreiben, und nicht, um das perfekte OOP-Klassendiagramm zu schreiben.Die Frage ist nicht, "wie kann ich verschiedene Arten von Getränken in OOP darstellen", sondern "wie kann ich meinem Programm ermöglichen, mit verschiedenen Arten von Getränken umzugehen". Die Antwort könnte sein, um sie in einer Klassenhierarchie mit einer gemeinsamen Drink-Basisklasse anzuordnen. Es könnte aber auch etwas anderes sein. Es könnte sein "alle Getränke gleich behandeln, und nur den Namen wechseln", in welchem ​​Fall eine Klasse reichlich ist. Oder es könnte sein, Getränke nur als eine andere Art von Verbrauchsmaterial oder nur als eine andere Art von Flüssigkeit zu behandeln, ohne ihre "trinkbare" Eigenschaft zu modellieren.

Wenn Sie einen Physiksimulator schreiben, dann sollten Sie vielleicht eine Batterie und eine Tasse Tee von der gleichen Basisklasse ableiten, da die Eigenschaft, die für Sie relevant ist, dass beide Energie speichern können. Und jetzt haben Saft und Tee plötzlich nichts gemeinsam. Sie könnten beide Getränke in einer anderen Welt sein, aber in Ihrer Bewerbung? Sie sind völlig verschieden. (Und bitte, keine Gewissensbisse darüber, wie Saft auch Energie enthält. Ich hätte ein Glas Wasser gesagt, aber dann würde jemand wohl Fusionskraft oder so etwas hervorbringen;))

Verliere nie dein Ziel aus den Augen. Warum müssen Sie Getränke in Ihrem Programm modellieren?

Answer 2

Es gibt zwei Lösungen für das Sugart-Problem. Die erste ist eine Unterklasse wie HotDrinks hinzufügen Whcih die addSugar enthält und addMilk wie:

    Drink 
       /\ 
      HotDrink Juice 
     / \ 
     Tea  Coffee 

Das Problem ist, dass diese unordentlich wird, wenn es eine Menge von diesen sind.

Die andere Lösung besteht darin, Schnittstellen hinzuzufügen. Jede Klasse kann null oder mehr Schnittstellen implementieren. Sie haben also die ISweetened und ICowPowerEnabled-Schnittstellen. Sowohl Tee als auch Kaffee implementieren die ISweetened- und die ICowPowerEnabled-Schnittstelle.

Answer 3

Objektorientiertes Design wird nicht isoliert durchgeführt. Die Frage, die Sie stellen müssen, ist, was muss meine spezifische Anwendung (wenn überhaupt) mit einer Getränkeklasse tun? Die Antwort und somit das Design unterscheiden sich von Anwendung zu Anwendung. Der Weg Nummer 1 bei OO zu versagen ist zu versuchen, perfekte platonische Klassenhierarchien zu konstruieren - solche Dinge existieren nur in vollkommenen platonischen Welten und sind in der realen Welt, in der wir leben, nicht nützlich.

Answer 4

viel helfen Dieses pdf Sie könnten und es passt perfekt zu Ihrem Beispiel:

The Decorator Pattern

Answer 5

Wenn Sie ein Neuling sind, würde ich keine Sorgen über nicht perfekt, Ihr Design-Muster zu bekommen. Tatsächlich würden viele argumentieren, dass es kein perfektes Designmuster gibt: P

Für Ihr Beispiel würde ich wahrscheinlich eine abstrakte Klasse für Getränke wie Tee und Kaffee erstellen (weil sie ähnliche Attribute teilen). Und versuchen Sie, die Getränkeklasse sehr wenige Attribute und Methoden zu haben. Wasser und Saft könnten sich von der abstrakten Getränkeklasse ableiten.

Answer 6

Zwei Dinge, die relevant sein könnten:

1) Neil Butterworth bringt sehr wichtige Unterscheidung zwischen einem Modell der realen Welt in einem bestimmten Kontext im Vergleich zu realer Welt selbst. Objektorientiertes Design wird manchmal auch als objektorientierte Modellierung bezeichnet. A model befasst sich nur mit den "interessanten" Aspekten der realen Welt. Was interessant ist, hängt vom Kontext Ihrer Anwendung ab.

2) Favour composition over inheritance. Ein Getränk hat Eigenschaften von Volumen und Temperatur (die in Ihrem Modellierungskontext möglicherweise relativ zur menschlichen Wahrnehmung sind, d. H. Extra kalt, kalt, warm, heiß) und besteht aus Zutaten (Wasser, Tee, Kaffee, Milch, Zucker, Aromen). Bitte beachten Sie, dass es nicht von Zutaten erbt, es ist aus ihnen gemacht. Soweit gute Wege zum Verfassen von Zutaten in die betreffenden Getränke versuchen decorator pattern.

Answer 7

Verwenden Sie Decorator Muster.

Answer 8

Um anderen Antworten hinzuzufügen, neigen Schnittstellen dazu, Ihnen größere Flexibilität bei der Entkopplung des Codes zu geben.

Sie müssen vorsichtig sein, ein Feature nicht mit einer Basisklasse zu verknüpfen, nur weil es allen abgeleiteten Klassen gemeinsam ist. Denken Sie eher darüber nach, ob diese Funktion extrahiert und auf andere, nicht verwandte Objekte angewendet werden kann - Sie werden feststellen, dass viele Methoden in Ihrer "echten" Basisklasse tatsächlich zu verschiedenen Schnittstellen gehören können.

Z. B. wenn Sie „die Zugabe von Zucker“ zu einem Getränke heute sind, können entscheiden, ob Sie es zu einem späterenPfannkuchen hinzuzufügen. Und dann könnten Sie am Ende mit Ihrem Code an vielen Stellen nach einem Drink fragen, mit AddSugar und verschiedenen anderen Methoden - es kann schwierig sein, sie umzugestalten.

Wenn Ihre Klasse weiß, wie etwas zu tun ist, kann sie die Schnittstelle unabhängig von implementieren, was die Klasse tatsächlich ist. Zum Beispiel:

interface IAcceptSugar 
{ 
    void AddSugar(); 
} 

public class Tea : IAcceptSugar { ... } 
public class Coffee : IAcceptSugar { ... } 
public class Pancake : IAcceptSugar { ... } 
public class SugarAddict : IAcceptSugar { ... } 

über eine Schnittstelle ein spezifisches Merkmal von dem Objekt anzufordern, die tatsächlich implementiert hilft es Ihnen, unabhängigen Code zu machen.

public void Sweeten(List<IAcceptSugar> items) 
{ 
    if (this.MustGetRidOfAllThisSugar) 
    { 
     // I want to get rid of my sugar, and 
     // frankly, I don't care what you guys 
     // do with it 

     foreach(IAcceptSugar item in items) 
      item.AddSugar(); 
    } 
} 

Ihr Code wird auch einfacher zu testen. Je einfacher die Schnittstelle ist, desto einfacher werden Sie die Verbraucher dieser Schnittstelle testen.

[Bearbeiten]

Vielleicht war ich nicht nicht ganz klar, so will ich klarstellen: Wenn AddSugar() macht die gleiche Sache für eine Gruppe von abgeleiteten Objekten, Sie werden es natürlich implementieren in ihrer Basisklasse. Aber in diesem Beispiel haben wir gesagt, dass Drink IAcceptSugar nicht immer implementieren muss.

So könnten wir mit einer gemeinsamen Klasse am Ende:

public class DrinkWithSugar : Drink, IAcceptSugar { ... } 

die AddSugar implementieren würde() die gleiche Art und Weise für ein paar Drinks.

Aber wenn Sie eines Tages erkennen, das ist nicht der beste Ort für Ihre Methode, müssen Sie andere Teile des Codes nicht ändern, wenn sie nur die Methode über die Schnittstelle verwenden.

Die Moral ist: Ihre Hierarchie kann sich ändern, solange Ihre Schnittstellen gleich bleiben.

Answer 9

Ein häufiger Fehler von neuen OO-Programmierern besteht darin, nicht zu erkennen, dass Vererbung für zwei verschiedene Zwecke, Polymorphismus und Wiederverwendung, verwendet wird. In einzelnen Vererbungssprachen müssen Sie normalerweise den Wiederverwendungsteil opfern und nur Polymorphie machen.

Ein weiterer Fehler ist die Verwendung der Vererbung. Während es eine gute Idee zu sein scheint, eine schöne Vererbungshierarchie zu entwerfen, ist es besser zu warten, bis ein polymorphes Problem auftaucht und dann die Vererbung erstellt.

Wenn Sie ein Problem haben, Klassen für 4 verschiedene Arten von Getränken zu erstellen, machen Sie 4 verschiedene Typen ohne Vererbung. Wenn Sie ein Problem bekommen, das besagt: "Ok, jetzt wollen wir einer Person diese Getränke geben und ausdrucken, was sie getrunken haben", dann ist das ein perfekter Polymorphismus. Fügen Sie eine Schnittstelle oder eine abstrakte Basisklasse mit einer Funktion drink() hinzu. Drücken Sie kompilieren, beachten Sie, dass alle 5 Klassen sagen, dass die Funktion nicht implementiert ist, implementieren Sie alle 5 Funktionen, drücken Sie kompilieren und Sie sind fertig.

Um Ihre Frage zu Ihrer Frage über das Hinzufügen von Milch oder Zucker, das Problem zu beantworten Ich gehe davon aus Sie laufen in ist, dass Sie ein Objekt Drinkable zu einem Person aber Drinkable übergeben wollen nicht addMilk oder addSugar hat. Dieses Problem kann auf zwei oder mehr Arten gelöst werden, einer ist ein sehr schlechter Weg, dies zu tun.

Die schlechte Art und Weise: Übergeben Sie eine Drinkable einen Person und eine Art Inspektion und Besetzung auf dem Objekt machen einen Tea oder Juice zu kommen.

void prepare (Drinkable drink) 
{ 
    if (drink is Juice) 
    { 
    Juice juice_drink = (Juick) drink; 
    juice_drink.thing(); 
    } 
} 

Eine Möglichkeit: Eine Möglichkeit ist, ein Getränk zu Person durch konkrete Klassen passieren und dann später zu trinken passieren.

class Person 
{ 
    void prepare_juice (Juice drink) 
    { 
    drink.thing1(); 
    } 
    void prepare_coffee (Coffee drink) 
    { 
    drink.addSugar(); 
    drink.addCream(); 
    } 
} 

Nachdem Sie die Person gebeten haben, das Getränk vorzubereiten, bitten Sie sie dann, es zu trinken.

Answer 10

Alles hängt von den Umständen ab - und das bedeutet wirklich - fangen Sie mit dem einfachsten Design an und refactor es, wenn Sie die Notwendigkeit sehen. Vielleicht würde es nicht sehr glänzend OOP aussehen - aber ich würde mit nur einer Klasse und einer Eigenschaft 'CanAddSugar' und 'SugarAmount' beginnen (später könnten Sie es zu einem Prädikat CanAddIngredient (IngredientName) verallgemeinern, so dass Menschen ihren Getränken Whiskey hinzufügen konnten:)

Es gibt eine tiefe Frage in all dem - welcher Unterschied zwischen zwei Objekten ist genug, um eine separate Klasse für sie zu erfordern? Ich habe keine gute Antwort darauf gesehen.