Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Als Hausarbeit für die Uni möchten wir ein kleines und einfaches Verwaltungstool mit Java realisieren.
Quasi so klein und einfach wie es mit nur 9 Monaten OOP-Erfahrung machbar ist.
Mein Kommilitone und ich sind uns uneinig darüber, ob wir für die Klasse "Warenhaus" Produkttypen wie "Maus", "Monitor", Tastatur" als Unterklassen anlegen sollen.
Alternativ hätten wir alle Attribute der "Maus", "Monitor", Tastatur" in die Klasse "Warenhaus" integriert.
Daher die Frage: Unter welchen Umständen ist es sinnvoll, für die Klasse "Warenhaus" Produkttypen wie "Maus", "Monitor", Tastatur" als Unterklassen anzulegen?
Wenn du damit meinst, dass Maus, Monitor und Tastatur jeweils Unterklassen von Warenhaus sein sollen, dann: Unter gar keinen Umständen.
Unterklassen drücken eine "ist-ein" Beziehung aus. Und weder eine Maus noch ein Monitor oder eine Tastatur ist ein Warenhaus.
Ein Warenhaus "hat" oder "besteht aus" einer Menge von Mäusen, Monitoren bzw. Tastaturen. Diese Dinge _sind_ aber kein Warenhaus.
Und bitte abstrahieren! Das hört sich recht dubios an, was Du da so schreibst. Ich will Waren mit eurer Software verwalten und nun will ich externe USB3 Festplatten mit aufnehmen. Dann muss ich um ein Software Update bitten, damit ihr mir eine neue Version gebt, die dann auch eine Klasse USB3Festplatte enthält?
Was wird denn in einem Warenhaus verwaltet? Das sind doch bestimmt Waren! Also habt ihr eine Klasse Waren. Und so ihr nicht bestimmte Verhaltensweisen benötigt, kann es das schon gewesen sein. Wenn es (für euer Programm) wichtige Verhaltensweisen gibt, dann gibt es neue Unterklassen. Aber auch da bitte abstrahiert! Also keine Klassen Tiefkühlpizza oder so, sondern dann habt ihr Kühlwaren / Tiefkühlwaren und so ...
Ja, was @kneitzel sagt, wäre dann: Wie macht man es denn in der Realität? Und dort möchte man selbstverständlich, wie er schon sagt, Flexibilität haben. Ich kenne aus meinem beruflichen Alltag auch ein Warenwirtschaftssystem und dort gibt es überhaupt keine Klassen für "Ware" oder "Produkt", sondern das ganze ist einfach ein riesen Persistenztopf mit Key-Value-Paaren als Attribute in einer Datenbank. Weil: Ich will ja auch dann meine Software nicht ändern/neu releasen müssen, wenn ein Produktmanager auf die Idee kommt: "Heute brauchen wir mal pro Produkt eine Sternebewertung" oder "Morgen möchte ich pro Produkt noch das Herkunftsland pflegen"... oder oder oder. Also, ich will auch in der Wahl meiner Produktattribute möglichst flexibel sein und eine Produktpflege-Oberfläche haben, in der ich einfach neue Daten pflegen kann.
Flexibilität ist dort absolut essentiell! Und dann ist das ganze System auch noch in mehrere Microservices aufgeteilt, die jeweils für sich noch eine Teildomäne mit eigenem Persistenzmodell abbilden. Da obliegt es natürlich dem jeweiligen Team selbst, hier entsprechende Abstraktionen und Modelle einzuführen.
Aber so wie ich den TE verstanden habe, geht es hier nur um eine "by the book"-OOP-Design Veranstaltung.
Das wahre Leben ist weitaus hässlicher und komplizierter.
Aber auch bei so einer Veranstaltung sollten die üblichen Regeln gelten.
Was unterscheidet für eure Applikation eine Maus von einer Tastatur? Oder was zeichnet diese aus?
Ihr könnt das gerne bauen. Aber dann wäre meine Erwartungshaltung, dass ihr lauter Klassen habt wir Maus extends Ware, Tastatur extends Ware u.s.w.
Und dann stellt ihr fest: In den Klassen wird keinerlei Spezialisierung durchgeführt. Beides sind einfach Kartons mit einer Größe, einer Beschriftung, ...
Und da es keine Spezialisierung gibt, steht ein Refactoring an. Und schwups: Verschwinden diese Klassen wieder....
Ggf. an dieser Stelle einfach Kent Becks "Test Driven Development: By Example" Buch nehmen und schauen, was ich da meine: Sein Money Beispiel am Anfang: Es gibt Dollar und Franc als Klassen und dann wird es im laufe der Entwicklung alles ersetzt. Denn die konkrete Währung hat nichts, was nicht direkt in Money abgebildet wird. (Wenn man das nicht kennt, dann ist es auch nicht so wild. Ich hoffe, dass ich es halbwegs vernünftig ausdrücken konnte.)
Ja natürlich. Ich habe ja auch nicht gegen dich argumentiert. Ich wollte nur versuchen, rüberzubringen, dass es eigentlich keine Regeln gibt, ausser: Designe die Anwendung nach dem konkreten Anwendungsfall und den Anforderungen. Wenn Flexibilität eine Anforderung ist, dann mach es so und so. Wenn es keine Anforderung ist, dann mach es nicht.
Alles was auch Amazon hat. Also Geräte, Bücher, Lebensmittel, Gutscheine
Also wären die Produktkategorien (Geräte, Bücher, Lebensmittel, Gutscheine) in der selben hierarchiestufe wie die Klasse Warenhaus,, obwohl diese sich in dem Warenhaus befinden? Oder soll ich alle Attribute der Produktkategorien (DPI, Auflösung, Gewicht, Gutscheinwert) in die Klasse "Warenhaus" integrieren?
Ist das eine Frage?
Falls ja: natürlich ist ein Politiker keine Partei. Eine Partei besteht aus Politikern.
EDIT: Wieso habe ich hier gerade das Gefühl, dass das eine eigentlich von dir als Hausaufgabe zu beantwortende Frage gewesen ist...., weil die gerade völlig aus dem Kontext gerissen erscheint und einfach nur etwas mit "Vererbung" zu tun hat.
Nein, auch nicht. Wie oben schon gesagt wurde, solltest du eine Klasse "Produkt" oder "GelagertesProdukt" machen, wo du alle Attribute eines Produktes aufnimmst, die alle Produktkategorien gemein haben.
An der Stelle noch ein Ratschlag: Vererbung sehr sehr sparsam einsetzen. In der Regel ist eine Komposition sinnvoller als Vererbung.
Selten ist es sinnvoll eine Vererbungshierarchie von Anfang an zu planen, meist ergibt sich das im Laufe der Zeit, dass man Gemeinsamkeiten aus getrennten Klassen herausextrahiert.
Ja natürlich. Ich habe ja auch nicht gegen dich argumentiert. Ich wollte nur versuchen, rüberzubringen, dass es eigentlich keine Regeln gibt, ausser: Designe die Anwendung nach dem konkreten Anwendungsfall und den Anforderungen. Wenn Flexibilität eine Anforderung ist, dann mach es so und so. Wenn es keine Anforderung ist, dann mach es nicht.
So hatte ich das auch nicht verstanden. Mir ging es jetzt auch mehr um die Thematik der Vorlesung / Übung / Praktika / was auch immer der Uni...
Denn der Punkt ist durchaus wichtig: Da kann die Uni tatsächlich irgend etwas fordern, was so wenig Sinn macht aber was klar befolgt werden muss. Also ich erinnere mich an "Software Engineering" - da hatten wir die Booch Method (War ein Vorläufer von UML). Und da war halt die Virgabe, dass alles Interface und Controller haben musste. Da wird nicht nach Sinn gefragt sondern es mussten Formalismen erfüllt werden.
Wenn sowas hier beim TE auch sein sollte, dann kann unsere Hilfe ggf. in die falsche Richtung laufen ...
Immer diese Panik ihr könntet versehentlich die Hausaufgaben von jemanden machen. Ich kann dich beruhigen: Das ist nicht strafbar.
Ich habe dieses "völlig aus dem Kontext gerissen" Beispiel ausgewählt, damit mein Komillitone und ich besser verstehen können wozu Unterklassen erstellt werden sollten.
Beim Verfassen von Fragen bekomme ich selbst schon das Gefühl ich habe irgendwas verbotenes getan, dank Leuten wie dir!
Und falls es dich beruhigt, du hast uns bei NUR einer Promille des Gesamtprojekts geholfen. Hoffentlich kann sich das mit deinem Gewissen vereinen, dass du uns nicht zu viel geholfen hast. Dein Arbeitgeber möchte ich nicht sein.
An der Stelle noch ein Ratschlag: Vererbung sehr sehr sparsam einsetzen. In der Regel ist eine Komposition sinnvoller als Vererbung.
Selten ist es sinnvoll eine Vererbungshierarchie von Anfang an zu planen, meist ergibt sich das im Laufe der Zeit, dass man Gemeinsamkeiten aus getrennten Klassen herausextrahiert.
Immer diese Panik ihr könntet versehentlich die Hausaufgaben von jemanden machen. Ich kann dich beruhigen: Das ist nicht strafbar.
Ich habe dieses "völlig aus dem Kontext gerissen" Beispiel ausgewählt, damit mein Komillitone und ich besser verstehen können wozu Unterklassen erstellt werden sollten.
Beim Verfassen von Fragen bekomme ich selbst schon das Gefühl ich habe irgendwas verbotenes getan, dank Leuten wie dir!
Wir wollen nur, das ihr etwas lernt. Die meisten hier kennen Gestalten die zwar ihr Studium (nicht selten sogar mit guten Noten) bestanden haben, fachlich aber völlige Nieten und eine Schande für den Berufsstand sind.
Wir helfen gerne weiter, wenn jemand Wissen und Kenntnis erlangen will - aber möchten auch eine gewisse Qualität sicherstellen. Niemand will mit Idioten zusammenarbeiten müssen. Also nimm es ihm nicht übel.
Noch etwas Senf zum Thema Vererbung:
Klassen sollen für gewöhnlich genau eine Aufgabe übernehmen. Was hätte 'Warenhaus' in eurem Fall für eine Aufgabe? Was hätte 'Ware' für eine Aufgabe?
Mit Vererbung sorgsam umzugehen ist richtig. Wenn Gemeinsamkeiten nicht sofort ins Auge springen, dann sollte man es lieber lassen.
Und es ist übrigens auch nicht immer gut, gleich eine Klasse zu bilden. Warum sollte z.B. 'Warengruppe' eine Klasse sein, was hätte sie für eine Aufgabe? Was wäre 'Tiefkühlbrötchen' z.B. für eine Warengruppe? Backware oder Tiefkühlware? Ihr könnt natürlich Tiefkühlware von Backware ableiten - was macht ihr dann mit Fischstäbchen? Wenn ihr Fisch in eurem Warenhaus suchen wollt, sollen Fischstäbchen und Heringkonserven in den Suchergebnissen auftauchen? Sollten Fischstäbchen und Heringkonserven zu einer Warengruppe Fisch gehören?
Ich glaube, es gibt da bessere Möglichkeiten.