mikrocontroller.net

Forum: PC-Programmierung Objekt-orientierter Ansatz hier richtig??


Autor: Alex Bürgel (Firma: Ucore Fotografie www.ucore.de) (alex22) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex Bürgel (Firma: Ucore Fotografie www.ucore.de) (alex22) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so, hatte ich vergessen: Es geht um C# :-)

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Alex Bürgel (Firma: Ucore Fotografie www.ucore.de) (alex22) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: Alex Bürgel (Firma: Ucore Fotografie www.ucore.de) (alex22) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Alex Bürgel (Firma: Ucore Fotografie www.ucore.de) (alex22) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex Bürgel (Firma: Ucore Fotografie www.ucore.de) (alex22) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex Bürgel (Firma: Ucore Fotografie www.ucore.de) (alex22) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-(

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.