spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

auch wenn david jetzt sauer wird, aber bei mir ist richtiges OOP das hier:

- Interfaces
- Vererbnung
- singletons (keine static-classes )
- STL
- OOP Gesetze
- Namespaces
- keine globalen variablen/funktionen
- Portabler Code
usw...

Ich werde nicht sauer, keine Angst. Dazu bedarf es schon ein wenig mehr
Allerdings zweifle ich einige Deiner Anführungen an...

- Was hat denn portabler Code mit OOP zu tun? Dann darf man doch schonmal garnicht mit DirectX programmieren, oder?
- Kann man ohne die STL nicht objektorientiert programmieren?

Und bitte sag mir mal, wo ich denn Vererbung hätte verwenden sollen. Ich sehe eigentlich keine Klassen, die man irgendwie erben könnte, außer halt bei tbGUI usw., aber da habe ich es ja auch gemacht.

Hi,

also ich programmiere am längsten hier in diesem Forum, und bin immer noch nicht diesem OOP-Wahn verfallen. Für mich ist ein Code, indem Klassen x-mal vererbt und mit zahlreichen Zugriffbeschränkungen "ausgestattet" ist einfach nicht so toll wiederverwendbar, wie es der ein oder andere OOP-Mensch gerne haben will. Es ist auch nicht so, dass jemand umso besser programmieren kann, je mehr OOP-Elemente er in seinen Projekten "verwirklicht". Ich kenne Profi-Coder, die nicht einmal prozedural programmieren, sondern rein linearen Code schreiben. Gut, das sind dann Spezialanwendungen.

In Büchern, z.B. Spieleprogrammierbüchern, finde ich OPP mehr als fehl am Platze, da ich null Bock drauf habe, in allen möglichen vererbten Klassen die relevanten Funktionen (und nur die interessieren mich ausschliesslich) zu suchen.

Nicht dass ich jetzt OOP generell ablehne, aber einen Wahn daraus zu machen, halte ich für hirnrissig...

ciao,
TomCat

juhu, einer der wie ich denkt!

Es gibt eben solche OOP-Wahnsinnige
Denen kann man es meistens auch nicht recht machen, zumindest nicht allen. Und falls das doch mal einer schaffen sollte, dann würde ich gerne mal den dazugehörigen Quellcode sehen... der würde wahrscheinlich tausende Zeilen abstraktes Zeugs enthalten. Wenn man alles zu stark abstrahiert, erkennt man am Ende garnicht mehr, was man eigentlich damit erreichen will, finde ich.
Und dauernd werden dann irgendwelche "OOP-Regeln" zitiert...

Hi,

beim coden geht es, wie auch im real-life, ausschliesslich darum, Probleme zu lösen. Wie man das macht, bleibt einem selbst überlassen.

ciao,
TomCat

Wenn mein Fernseher kaputt ist, und ich keinen neuen kaufen will, kann ich:
- Ihn von einer Firma reparieren lassen.
- Eine eigene Firma gründen, die defekte technische Geräte annimmt und sie an andere Firmen zur Reparatur weiterleitet. Dann gründe ich eine Tochterfirma (eine "abgeleitete Firma"), die speziell für Fernseher zuständig ist. Nun bringe ich meiner eigenen Firma meinen defekten Fernseher und sie leitet ihn weiter an einen Reparatur-Service. Danach löse ich beide Firmen wieder auf.

Was ist wohl einfacher?

Hi,

selbstverständlich könnte man das.
Es ist aber manchmal von Vorteil etwas in eine Klasse zu packen, um dann beliebig viele Objekte davon zu erzeugen.

Sehr anschaulich wird das hier erklärt:

http://www.poke53280.de/articel2/index.php?artcat=5

ciao,
TomCat