2016-05-07 10 views
2

erben, habe ich das folgende Klassendiagramm. Ich suchte nur nach einer Anleitung, wie ich diese Prüfungsfrage angehen konnte, da ich mir nicht sicher bin, ob ich Recht hatte. Ich habe keine Lösungen gehofft, dass jemand mit mehr Erfahrung dort seine Meinung geben könnte.Sollte diese Klasse direkt von der Basisklasse oder von der Unterklasse

enter image description here

  • TASK 1: eine Unterklasse MonsterEater genannt hinzufügen. Objekte dieser Klasse sind wie PieEaters, aber zusätzlich hat die MonsterEater ein Attribut mit dem Namen numPieEatersEaten vom Typ Integer und eine Methode eatPieEater mit der Signatur eines Arguments mit dem Namen aGrid, das vom Typ Grid ist.

    Seit MonsterEater hat eine Menge von der gleichen Verhaltensweisen wie PieEater ich von der PieEater Klasse, die erben machen beschlossen, während sie das zusätzliche Verhalten geben (Attribute und Methoden)

  • TASK 2: Fügen Sie eine Unterklasse genannt MagicPie. Objekte dieser Klasse sind wie Pies zusätzlich aber die MagicPies haben ein Attribut visible vom Typ boolean genannt und Methoden erscheinen und verschwinden beide mit Unterschrift ohne Argumente und Rück nichts

    ich MagicPie vererben Pie gemacht. Habe ihm die Attribute und Methoden gegeben.

  • TASK 3: Überschreiben Sie die Anzeigemethode in allen konkreten Klassen in Ihrer Vererbungshierarchie.

    Dazu habe ich gerade die Methode display() zu allen Klassen hinzugefügt, die von der Basisklasse GameElement erben.

    Ich wurde auch gebeten, eine Zuordnung hinzuzufügen, so dass nur MonsterEatersMagicPies essen kann (die Klasse i von Pie ableiten Made) so habe ich eine eats Vereinigung von MonsterEater zu MagicPie

  • letzte Aufgabe gemacht.: Listen Sie alle Funktionen der Klassen MonsterEater und MagicPie auf. Ermöglicht das von Ihnen erstellte UML-Diagramm MonsterEatersPies zu essen. Erkläre deine Antwort.

    Ich war nicht sicher über diese, MonsterEater erbt von der PieEater Klasse, die einen Kuchen essen kann, aber ich bin mir nicht sicher, ob das bedeutet MonsterEater kann. Ich bin mir auch nicht ganz sicher, ob meine von mir erstellte Vererbungshierarchie überhaupt richtig ist. Jede Einsicht/Anleitung würde sehr geschätzt werden.

Antwort

-1

Ich würde nicht zulassen, MonsterEater von PieEater erben, wenn es nicht Pasteten frißt, die Tatsache, dass sie beide essen/gehen/drehen Methoden bedeutet dies wahrscheinlich, sollten sie einige neue Schnittstellen implementieren: IEater, iWalker.

Ein MagicPie, das von einem Pie erbt, macht mehr Sinn, da es sich um eine Erweiterung eines normalen Pie handelt.

Je nach verwendetem UML-Tool müssen Sie möglicherweise festlegen, dass display() eine Überschreibung ist.

Die letzte Frage, wieder zu meiner ersten Beobachtung, es ist eine Frage der Anforderungen, können Sie es in beide Richtungen tun, wenn es nicht angegeben ist, würde ich nicht davon ausgehen, dass ein MonsterEater einen Kuchen essen kann.

EDIT: Wenn Sie die Mehrfachvererbung verwenden dürfen, können Sie auch Klassen anstelle von Schnittstellen für Eater/Walker verwenden.

+0

Ja das macht Sinn, danke. Obwohl MonsterEater die eatpie() -Methode hat, kann die Tatsache, dass es keine Essensassoziation zu Pie hat, annehmen, dass es keinen Kuchen essen kann. Was wären die Features? die Dinge, die es tun kann? –

+0

Und am Ende wurde ich gebeten, in Bezug auf die Basisklasse, Unterklasse und Blatt-Klassen zu kennzeichnen, ich verstehe, wie man alles mit Ausnahme der Gitterklasse beschriftet. wäre das eine Basisklasse? –

+0

Das wäre wieder das Design, aber, ohne einen Erben zu haben, ist es eine Blattklasse. Um zu verhindern, dass Unterklassen vorhanden sind, sollte es einen Stereotyp "versiegelt/endgültig" haben. Aber ich denke, jetzt denke ich zu viel über die Implementierung in Sprachen nach. – user4388177

0

Aufgabe 1: Wenn MonsterEater auch Pie essen darf, dann scheint Ihre Vererbungsbeziehung akzeptabel. Ich würde auch eine Assoziation 0..1 zu 0..n von MonsterEater zu PieEater hinzufügen. Dies macht die Implikation dieser Vererbung offensichtlich: Eine MonsterEater kann auch eine andere MonsterEater essen, weil es auch eine PieEater ist.

Aufgabe 2: Die Vererbung Sinn macht, wie intuitiv ein MagicPie ist eine besondere Art von Pie. Aber die Folge dieser Erbschaft, ist, dass PieEater auch MagicPie essen kann (siehe unten)

Aufgabe 3: ok für das Display. ok für die zusätzliche Assoziation. Aber hier ist eine Falle. Als MagicPie ist ein Pie, ein PieEater könnte auch eine MagicPie essen. Also müssen Sie eine Einschränkung des bestehenden Verein hinzufügen zwischen PieEater und Pie, zum Beispiel: { Pie shall not be a MagicPie }

Aufgabe 4: für Ernährung, siehe oben. Die Erbschaft, die Sie gemacht haben, scheint vernünftig zu sein. Der Wortlaut der Anweisungen "sind wie ... aber zusätzlich ..." deutet stark auf Vererbung hin. Nur wenn MonsterEater nicht erlaubt wäre zu essen Pie würde ich ernsthaft diese Vererbung in Frage stellen. Und das ist nicht ausdrücklich verboten.

+0

danke würde ich recht damit sagen, dass ein monserEater auch einen tortenkuchen essen könnte als monsterEater ist auch ein pieEater? Würde ich diese Assoziation zeigen müssen oder würde durch die Assoziation pieEater its pie angedeutet? Es fragt auch nach den Eigenschaften der monsterEater und magicPie Klasse, was wären sie? –

+0

@stephenreilly ja, du hättest recht. Die Assoziation ist impliziert, es muss nicht gezeigt werden. Für die Features würde ich diejenigen der Klasse und deren Eltern auflisten. – Christophe

+0

wie in Liste all die Dinge, die es tun kann? wie einen Kuchen essen, gehen, drehen etc. –