Hallo! Ich bin noch nicht so erfahren auf dem Gebiet der o-o Programmierung und kann daher noch nicht abschätzen ob sie bei meinem aktuellen Programm signifikante Vorteile bietet. Zum Programm: Es handelt sich um eine grafische Windows-Anwendung. Es ist eine Art "Turnierplaner", d.h. zu Beginn gibt man eine beliebige Anzahl an Spielern (mit ihren Namen) ein und legt ein Team-Verhältnis (1 vs 1, 2 vs 2 etc.) fest. Klickt man jetzt auf "Berechnen" zeigt das Programm eine Tabelle mit allen Kombinationen der Teams und Spieler aus, also bei 4 Spielern und 2 vs 2 wären es dann z.b. Spieler1&Spieler2 vs Spieler3&Spieler4 + Spieler1&Spieler3 vs Spieler2&Spieler4 + Spieler1&Spieler4 vs Spieler2&Spieler3. In diese Tabelle kann man dann die jeweils erzielten Spielergebnisse eintragen und das Programm zeigt dann Punktelisten an, z.B. wer die meisten Spiele gewonnen hat etc. So, bisher läuft das alles, abgesehen von der GUI natürlich, rein über Funktionen ab... Könnte man das o-o besser lösen??? Wie??? Jeder Spieler, jedes Spiel und jedes Team jeweils ein eigenes Objekt der Klassen: Spieler, Spiel, Team? Für Tipps und Vorschläge wäre ich sehr dankbar!! Schöne Grüße, Alex
Natürlich könnteste jetzt auf Biegen und Brechen (und Schul-Informatik-Manier) Objekte benutzen. Aber frag dich doch mal selbst: Würde so ein Objekt irgendwas andres machen, außer seine Daten zu behalten? Also ich meine, gäb es irgendnen Fall, wo du (abgesehen von den Daten selbst) irgendetwas von einem Objekt verlangen würdes (Objekt -- tu was!)? Wenn nicht, dann hat sich deine Frage wohl mit der Überlegung erledigt, oder? Und nur damit du den Konstruktor hast... nee, das geht über ne Funktion genauso elegant. Könntest zwar Spiele und Teams in Objekte verpacken, aber da du letztlich ja doch wieder nur Daten ablegst, würd ich da ganz schlapp zu den Standard-C++-Vorlagen raten: * Ein Spieler --> eine Struktur (struct) * Ein Team --> ein Satz oder eine Liste von Spielern (bzw. Zeigern, je nach dem) * Eine Begegnung --> ein Pärchen von zwei Teams * Ein Spiel --> eine Liste von Begegnungen. Du brauchst nur die üblichen Verdächtigen (deque etc.). Also was ich unterm Strich damit sagen will: Es macht praktisch keinen Sinn, ein Objekt für "etwas" anzulegen, was nur einmal gebraucht wird. Deine Datenstrukturen sind ja kontextfrei, weil sowieso alles offenliegen muss. Gut, wenn du jetzt mit 100 andren Leuten programmierst, kann man so gescheite Schnittstellen umsetzen, was aber andrerseits auch mit sauber kommentiertem Quelltext ebensogut funktioniert (Kapselung). Muss allerdings auch gestehen: Ich bin kein sonderlich großer Freund von C++; ich mag klassisches C lieber.
Ach so, hatte ich vergessen: Es geht um C# :-)
Alex Bürgel wrote:
> Ach so, hatte ich vergessen: Es geht um C# :-)
Ist auch Latte, ich hab die miesen Erfahrungen mit Delphi in der Schule
gesammelt...
Würde sich denn hier wohl die Verwendung von ADO.NET lohnen um die ganzen Begegnungen und Spieler etc. zu speichern und durchsuchen zu können?
Alex Bürgel wrote: > Würde sich denn hier wohl die Verwendung von ADO.NET lohnen um die > ganzen Begegnungen und Spieler etc. zu speichern und durchsuchen zu > können? Um den Microsoft-Mist von wegen DAO und ADO mach mal lieber einen großen Bogen drum, vorallem um Microsoft Access. Andre Frage: Wie viele Datensätze wird es denn geben...? Vermutlich bist du mit Textdateien besser bedient. Insofern denk ich net, dass sich ne Datenbank groß lohnen würde.
>> Würde sich denn hier wohl die Verwendung von ADO.NET lohnen um die >> ganzen Begegnungen und Spieler etc. zu speichern und durchsuchen zu >> können? >Um den Microsoft-Mist von wegen DAO und ADO mach mal lieber einen großen >Bogen drum, vorallem um Microsoft Access. Ach bitte, ADO.NET ist zunächst einmal nur ein API um auf Datenbanken zuzugreifen, und nicht einmal so ein schlechtes. Und mit Access hat es speziell nichts zu tun (aber natürlich gibts auch ADO.NET Provider für Jet-Datenbanken, die funktionieren übrigens auch ganz gut) Ahem...es gibt sogar irgendeinen ADO.NET Provider um auf CSV-Dateien zuzugreifen :D
Naja, also zur Zeit spielen wir ein Kicker-Turnier mit 13 Personen, immer 2 gegen 2. Das sind dann schon 660 Spiele pro Person und insgesamt knapp 2400 Spiele. Bis das ein PC mit 1 GHz das alles berechnet hat dauert es bei der aktuellen Programmierung fast 5 Sekunden. Ich hatte gehofft das irgendwie optimieren zu können...
P.S. Im Moment speichert der PC auch alle Spiele in einem Array. Da die maximale Größe eines Arrays aber scheinbar auf irgendwas um 30 Millionen Zeilen begrenzt ist (warum auch immer) könnten an dem Turnier nur maximal 22 Leute oder so teilnehmen...
Bartli wrote: >>> Würde sich denn hier wohl die Verwendung von ADO.NET lohnen um die >>> ganzen Begegnungen und Spieler etc. zu speichern und durchsuchen zu >>> können? > >>Um den Microsoft-Mist von wegen DAO und ADO mach mal lieber einen großen >>Bogen drum, vorallem um Microsoft Access. > > Ach bitte, ADO.NET ist zunächst einmal nur ein API um auf Datenbanken > zuzugreifen, und nicht einmal so ein schlechtes. Weiß ich doch, hab mich ausgiebig damit herumgeschlagen, aber sooo dolle isses nu auch net. Ist mir zu undurchsichtig -- Borland hat da was Besseres im Angebot, aber andres Thema. > Und mit Access hat es > speziell nichts zu tun (aber natürlich gibts auch ADO.NET Provider für > Jet-Datenbanken, die funktionieren übrigens auch ganz gut) Klar. Access ist (war?) nur ziemlich unausgereift (Beispiel: die Datenbanken wachsen immer weiter, wenn man kontinuierlich einen Datensatz einfügt, ihn wieder löscht, wieder einen einfügt usw. Das ist Murks, da ist auch die Datenbankoptimierung keine tragbare Ausrede mehr). > Ahem...es gibt sogar irgendeinen ADO.NET Provider um auf CSV-Dateien > zuzugreifen :D Jubb, den gibts. Wie gesagt, überlegs dir gut. Wenn ihr doch schon so weit seit: Spiel doch mal mit dem Gedanken, dich beispielsweise in PHP und MySQL/PostgreSQL einzuarbeiten (alles freie Software) und dann dein Programm mit Webinterface zu gestalten (nur mit Webinterface). Quasi wie in einem Intranet: Wenn gespielt wird, kannstu mit XAMPP das Ganze lokal laufen lassen und danach (ggf. sogar zeitgleich) die aktuellen Spielstände im Internet/auf Terminals/Bildschirmen veröffentlichen.
>nur mit Webinterface
mit php und mySQL kenne ich mich deutlich besser aus als mit C#, das
wäre kein Problem. Allerdings stören mich daran drei Sachen:
1. Müsste man dann immer einen Web-Server und einen Datenbank-Server
laufen lassen.
2. Sähe es bestimmt nicht so hübsch aus, da es "nur" eine Webseite
innerhalb eines Browsers wäre.
3. Wäre es mit an Sicherheit grenzender Wahrscheinlichkeit langsamer.
Hmm, gibt es in C# eigentlich nicht so etwas wie Layouts, wie man sie
aus Java.awt gibt? Z.B. Borderlayout...
Ist die Speicherung sämtlicher Sachen in Arrays hier echt das beste?
Schöne Grüße,
Alex
P.S. Ach so, es gibt übrigens bereits eine "Export to html"-Funktion die
sämtliche Tabellen als html exportiert.
Alex Bürgel wrote: >>nur mit Webinterface > > mit php und mySQL kenne ich mich deutlich besser aus als mit C#, das > wäre kein Problem. > Allerdings stören mich daran drei Sachen: > 1. Müsste man dann immer einen Web-Server und einen Datenbank-Server > laufen lassen. Ist doch kein Problem, der Server braucht im Leerlauf nix, und die Datenbank auch net. Im Zweifelsfall z.B. SQLite benutzen -- läuft ohne Server. Das wär evtl. auch was für dein C#-Programm! > 2. Sähe es bestimmt nicht so hübsch aus, da es "nur" eine Webseite > innerhalb eines Browsers wäre. Säh im Vergleich zu Windows-Tabellen-Gefrickel und Rumzeichnen mit GDI vermutlich wunderschön aus -- denk dran, es gibt auch noch CSS und Bilder! > 3. Wäre es mit an Sicherheit grenzender Wahrscheinlichkeit langsamer. Nö, das is Käse. Was soll da langsam sein? Die Zehntelsekunde, die der Webserver braucht? > Hmm, gibt es in C# eigentlich nicht so etwas wie Layouts, wie man sie > aus Java.awt gibt? Z.B. Borderlayout... Leider keine Ahnung... > Ist die Speicherung sämtlicher Sachen in Arrays hier echt das beste? Ne, wie ich oben gesagt hab: nimm Standard-Vorlagen (Templates), vector, deque, Tupele und sowas. > P.S. Ach so, es gibt übrigens bereits eine "Export to html"-Funktion die > sämtliche Tabellen als html exportiert. Die könnteste dir mit PHP vermutlich schenken ;-) Wie gesagt -- wenn du dich doch mit PHP auskennst, dann wär ich an deiner Stelle doch nich so blöde (weißt wohl, wie ichs meine), mir noch C# aufzuhalsen -- du müsstest doch um die Flexibilität von PHP wissen, nutz doch deine Fertigkeiten einfach!
Alex Bürgel wrote: > Naja, also zur Zeit spielen wir ein Kicker-Turnier mit 13 Personen, > immer 2 gegen 2. Das sind dann schon 660 Spiele pro Person und insgesamt > knapp 2400 Spiele. Bis das ein PC mit 1 GHz das alles berechnet hat > dauert es bei der aktuellen Programmierung fast 5 Sekunden. Wie bitte? Weist du wieviel ein derartiger PC in 5 Sekunden schafft? > Ich hatte > gehofft das irgendwie optimieren zu können... Das denke ich allerdings auch. Da hast du irgendwo einen grossen Bock geschossen. Bei deinem Mengengerüst darf die CPU noch nicht mal richtig warmlaufen ehe sie bereits wieder fertig ist.
Ich fürchte das der PC so lange dafür braucht liegt daran, dass zur Zeit jede Begegnung in Form eines zusammengesetzten Strings aus mehreren Teilstrings (die Spielernamen) in ein Array geschrieben wird. Und prinzipiell berechnet mein Algorithmus jede Mögliche Kombination der Spieler und guckt dann, ob diese Kombination eventuell schon mal (nur in anderer Reihenfolge) im Array vorhanden ist... Das ist sicherlich sehr suboptimal :-(
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.