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 :-(