[c++] Klassen für Quizspiel

[Newbie44]

Hallo,

ich bräuchte mal eure Hilfe. Ich hab schon einiges in OOP gemacht jedoch habe ich Probleme die richtigen klassen zu finden.

ich möchte so eine art "wer wird Millionär" nachprogrammieren, also mit jokern und allen was dazugehört. aber ich habe ein problem die richtigen klassen dafür zu finden.

soll ich jede frage als eigenes objekt sehen?

eine frage hat ja im Prinzip 4 antworten, von denen der 50:50 joker 2 falsche entfernen kann.

kann mir jemand hier bitte ein paar Tipps geben wie ich die klassen richtig setze? vielleicht könnt ihr mir es auch erklären wieso ihr es so machen würdet und nicht anders.

bitte nur die Klassenhierarchie posten und nicht gleich mit viel Inhalt.

vielen vielen dank für eure Hilfe, ich poste das hier rein in ein delphi forum, da ich hier kompetentere antwort erhalten habe als in einem c++ Fachforum.

gruß und danke

sebastian

[Der_Unwissende]

Hi,
die Frage ist in der Form erstmal völlig unabhängig von C++ (kannst Du also theoretisch aus dem Titel entfernen und damit auf mehr Antworten hoffen). An sich ist es ein reines OO Problem.
Das schöne an der OO ist, dass es (wie auch in der logischen, imperativen, funktionalen, ... Programmierung) nicht nur eine Lösung gibt.

Es kann Dir also keiner die eine richtige Klassenhierachie vorgeben, die genau das tut, was Du möchtest. Der einfachste Grund, warum das nicht möglich ist, liegt schon darin, dass keiner weiß was Du genau machen möchtest. Du möchtest "Wer wir Millionär" nachprogrammieren, ok, ist 'ne Fernsehsendung, wie programmiert man einen Jauch? Es kommt ja doch ein wenig darauf an, an was für eine Umsetzung Du überhaupt (erstmal?) gedacht hast. Von den Problemen, die Du lösen möchtest hängt natürlich ab, was für Klassen man erzeugen kann (und auch da gibt es dann verschiedene Ansätze mit unterschiedlichem Fokus). Objekt Orientierung heißt ja nun nicht, dass man alles in Klassen steckt und gut ist. Es gibt ja einen Grund, warum man klassifiziert und abstrahiert. Ich muss ehrlich sagen, dass ich mir nicht ganz sicher bin, ob Du da schon den Sinn komplett verstanden hast.

Würde sich jetzt jmd. die Mühe machen und eine Klassenhierachie posten, ohne näher auf diese einzugehen, dann wäre es für Dich ehrlich gesagt völlig wertlos. Du hast dann nur eine Übersicht der Klassen, die jmd. verwenden würde, um seine Umsetzung von Wer wird Millionär zu realisieren. Worauf diese basiert bleibt für Dich dann ebenso unklar, wie die Eigenschaften der einzelnen Klassen. Es ist doch eher unwahrscheinlich, dass alle Klassen so toll benannt sein dürften, dass Du immer sofort (und ohne Irrtum) wüßtest, was genau der Autor sich dabei dachte bzw. was die Klasse alles leisten soll/muss und was eben nicht.
Einfaches Beispiel, sagen wir mal ich würde in einer Klassenhierachie TLanguage verwenden, was heißt das für Dich? Möchte ich die Texte in verschiedenen Sprachen anbieten? Möchte ich Sprachausgabe betreiben? Oder ist die für das Zeichnen des Publikums zuständig und ich hab die nur scheiße benannt?! Natürlich könnte auch alles zu treffen!

Viel besser ist es also, wenn Du Dir erstmal Gedanken machst, was genau Du alles umsetzen möchtest. Das ganze musst Du dann modellieren. An sich bietet es sich dabei immer an, dass Du Subsystem extrahierst. Hast Du also ein großes Problem (Wer wird Millionär umsetzen), dann lässt sich das immer in kleinere Teilprobleme zerlegen (Publikum, Moderator, Kandidat, Fragen, Gewinn). So kannst Du natürlich rekursiv weiter machen, so kann man Fragen weiter unterteilen in den eigentlichen Fragenkatalog, die Joker und natürlich auch die Auswertung (ob die Frage korrekt beantwortet wurde oder nicht), wie die ausgewählt werden usw. Du merkst schon, dass man auch die erste Einteilung anders hätte machen können.
An sich solltest Du immer schauen, dass Du zusammengehörige Probleme in einem Subsystem zusammenfasst. Pro Hierachiestufe solltest Du (um einen Überblick zu behalten) immer so max. 7 (+/- 3) Subsysteme suchen (ist kein Pflichtwert, aber ist gut zur Orientierung). Je komplexer das Gesamtproblem, desto mehr Stufen brauchst Du halt, da die erste Zerlegung extrem grob ist. Wie Du die Probleme kategorisierst solltest Du aber selbst überlegen. Eine Alternative wäre z.B. auch, dass Du erstmal zwischen der Darstellung (z.B. Grafiken, OpenGL/ActiveX, Textausgabe,...), dem eigentlichen Spielablauf (Umsetzung der Regeln, mögliche Züge, ...) und der Speicherung der Daten unterscheidest. Gibt noch jede Menge (sinnvollere) andere Aufbauten die möglich sind.

Beim zerlegen erreichst Du übrigens irgendwann einen Punkt, an dem eine weitere Zerlegung nicht wirklich sinnvoll erscheint. Dann hast Du eine Menge von Problemen, die man gut zusammenfassen kann. Das ist dann eine gute Basis für eine Klasse. Der Objekt Orientierte Teil beim Zerlegen besteht übrigens darin, dass Du sehr abstrakt ran gehst. Nehmen wir also als Beispiel die Darstellung von Personen, die irgendwie den Moderator, irgendwie den Kandidaten und ggf. auch das Publikum darstellt. Hier gibt es also ein bestimmte Punkte die für alle gleich sind (sie müssen angezeigt werden) und bestimmte Merkmale die sich unterscheiden (das konkrete Aussehen, der Sitzplatz). Das, was nun alle gemeinsam haben lässt sich also auch in einer Basisklasse lösen, die individuellen Merkmale hingegen auf eine Spezialisierung abbilden (die hier vorgegebenen Punkte sind nur exemplarisch und müssen nicht unbedingt Sinn machen!).

So kannst Du Dir für Deine Überlegungen eine eigene Objekthierachie erstellen. Das A und O dabei, kommentiere sie! Dokumentiere gut, warum Du gerade so und nicht anders modellierst. Schon bei kleinen Projekten blickst Du sonst schnell mal auf Dein Modell und weißt leider überhaupt nicht, warum dies so und nicht anders ist oder was eine bestimmte Klasse leisten soll. Da stehst Du dann vor dem selben Problem, dass Du eben auch hättest wenn Du nur eine Hierachie bekommst, es hilft keinem. Hast Du dann eine eigene Hierachie und die zugehörige Dokumentation, dann kannst Du die natürlich super im Forum diskutieren und es können Verbesserungsvorschläge gemacht werden.

Gruß,
Der Unwissende