spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Also ich kann dir schon mal so weit helfen:

Professionelles Programmieren ist Programmieren für Geld. Jaja OpenSource "Ole ole!", aber auch Programmierer sterben wenn sie nicht essen. Professionalität hat nichts mit Qualität zu tun. Aber wenn die Welt gerecht ist lebt der schlechte professionelle Programmierer von Wasser und Brot und der gute professionelle Programmierer von Kaviar und Wein[ich hasse dieses Zeug ;-)]. ABer niemand garantiert dass die Welt gerecht ist.

Hi,

naja Objektorientiertes Design ist ein sehr flexibles Unterfangen aber auch mit vielen Regeln, Privilegien und co. Am Ende kommt immer etwas anderes hinaus.

Viele sagen "Mach es so ansonsten ist es falsch!". Zwar ist oft was wahres dran, aber oft ist es nur Dünnschiss.

Bestes Beispiel: Operator +-*/ habe ich vorher immer in einer Klasse implementiert und den Operator +=,-=,*=,/= darüber implementiert, neuerdings ist es anders herum, dank learning by doing und scott meyers.

Heute sind die +-*/ operatoren außerhalb der Klasse und die x= operatoren innerhalb der klasse und anders herum implemenetiert.

"M.E. ergibt sich beim langjährigen C Programmieren schon automatisch ein Stil in Richtung OO. "
Meiner Meinung nach ist dem nicht so, ich habe vorher 2-3 Jahre in ANSI C gecodet und nicht sehr viel von OO gehalten. Aber bei jedem ist es ja anders

"M.E. sollten alle Programme OO sein bis auf sehr sehr kleine."
Ziel von OOP war es bisher immer das die Klassen "wiederverwendbar" sind, so wie Legobausteine (Siehe COM). Daher macht es meiner Meinung nach sehr viel Sinn auch in kleinen Programmen OOP zu benutzen. Aber auch ansichtssache

"Ich hab aber noch keinen gesehen, der es in z.B. C++ nutzt. Warum ???"
Weil es nicht anwendbar ist und gegen die anderen "Regeln" und Privilegien von C++ verstößt, bestes Beispiel das OCP.

"Wenn ich von verschiedenen Philosophien rede, dann meine ich unter anderem Regeln wie keine einzige globale Variable, kein einziges Define, alle Programm sollen OO benutzen, alle Programmteile sollen OO benutzen, Netzwerkzugriff muss transparent sein etc. Ich habe da durchaus meine eigene Meinung dazu :angel: "
Naja OOP wiederspricht aber auch oft dem Faktor Speed, drum sollte man an diversen Stellen des Programms auf OOP scheißen (ums mal hart auszudrücken) oder die OOP richtlinien umgehen, weil sonst macht es echt keinen Sinn.

"Man kann auch drüber nachdenken, was bedeutet "professionelles" programmieren? Da habe ich auch noich nicht sooo viel drüber gelesen."
Das ist bei jedem anders, wie der "Sinn des Lebens", für mich ist es wiederverwendbarkeit nach dem Legoprinzip und schnelligkeit.

"3D Vektor aus einem 2D Vektor ableitet"
Um Gottes Willen! Wer zum Geier macht den so etwas? Ich benutze nur 1 vector klasse (auch im Buch) für 1d-4d und bin vollkommen damit ausgestattet egal ob es sich um 2D, 3D oder 4D handelt. Aber ableiten? Das verursacht zuviel Mehrfachvererbung und ist meiner Meinung nach total unzumutbar.

naja das wars von mir ;D

- Patrick

Hi,

naja bugs mit OOP zu vermeiden ist so ne sache, mit gutem ANSI C kann man auch bugfrei coden und braucht kein OOP dafür

Erfahrungen mit wiederverwendbarkeit?

siehe dies hier:
http://www.scherfgen-software.net/forum/viewtopic.php?t=2340

oder anderes beispiel: ich habe jetzt eine Loggingklasse seit ca. 4 jahren und an ihr selber häufig was gebastelt habe (updates) aber ein redesign und co. würde für mich nie in frage kommen, weil es meinem Design nach nicht besser gehen könnte.

Aber das mit dem vector? grauenhaft ;D;D;D

Kay, ich gebe zu ich war nicht in philosophischer Stimmung und hätte daher wohl besser schweigen sollen. :angel:

OOP Philosophien gibt es genauso viele wie Meinungen über "welche Sprache ist besser/schneller". Daher kann auch nur jeder seine Meinug dazugeben (solange er sie auch begründen kann) und fertig.

Was Bücher angeht. KA. hab nur die C++ Bibel und da steht schon viel drinn. Zusammen mit "Entwufsmuster" ist das eine sehr Lehreiche angelegenheit. Ich muss ehrlich zugeben. Alle Regeln von OOP kenne ich nicht. Denn das Regelwerk oder besser gesagt der Rahmen in dem man OO programmieren kann, ist von der Sprache abhängig. C++ stellt schon viele Sprachmittel zur verfügung um OO zu Pogrammieren. Andere stellen vieleicht bessere oder mehr Sprachmittel zur verfügung.

Was die Wiederverwendbarkeit angeht. Ein Aspekt ist sicherlich das man Objekte wieder verwenden können soll. Aber letztenendes liegt es am Design. Zudem muss man sagen. Wiederverwendbarkeit gibt es nicht erst seit OOD. Das kann man auch z.B. mit Ansi C machen. Es kommt schlicht auf das Design des Codes an. Ein schlechter OO Code kann auch nur schlecht wiederverwendet werden.

Dann aber stellt sich immer die Frage. Wann ist ein Code schlecht und wann ist er gut? Ich denke das man das gar nicht so genau sagen kann, weil es schlicht auf das Projekt und dem eigenen Code ankommt, damit man ein bestehendes Objekt in seinen Code Integrieren kann.
Sicherlicht ein gut Dokumentierter und aufgeräumter Code macht es einfacher. Aber hier sind wir ja schon nicht mehr bei OOD sondern beim Programmstil.


Einige Sagen OO programmiere ich nicht. Andere sagen. Ich programmiere nur OO. Nun in meinem aktuellen Projekt will ich möglichst nur OO Elemente besitzen. Was sicher keine objektive Entscheidung war. Bei einer objektiven Entscheidung hätte ich ein Mix vorgegeben. Denn wie Patrick schon sagte. An einigen stellen sollte man OOP über Bord werfen. Der Performance zu liebe. Aber hier stellt sich dann auch wieder die Frage, welches Programm man Entwickelt. Für ein Office Packet ist ein reines OOD sicherlich besser. Da viele Elemente ausgetauscht oder erweitert werden müssen. Und auf Performance kommt es hier auch nicht so an. Bei Spielen sieht das wieder anders aus.

Und Bug-Freier programmieren mit OO? Hmm...wohl eher nicht. Bug-Frei kann man auch mit anderen Sprachen programmieren. Dafür braucht man kein OOD.


Weiter oben habe ich geschrieben das ich das Buch "Entwurfsmuster" habe. Dort sind sehr viele Techniken (Designe Patterns) beschrieben. Für die verschiedensten Aufgaben. Es wird sogar beschrieben, welche gut zusammen Arbeiten. Aber Schlußendlich kommt es dann doch darauf an, welche Projekt man verfolgt. Jedes Projekt stellt verschiedenen Anforderungen und die müssen mit verschiedenen Lösungen gelöst werden. Daher sagte ich auch im besagten Thread. Das Patrick in seinem Buch doch eher eine Abhandlung über OOD schreiben solle als eine Einführung in C++. Denn das Game Design stellt sehr viele Anforderungen.


Für mich stellt OOD vor allem ein Werkzeug dar. Das mir erlaubt schnell und einfach eine Schnittstelle für ein Objekt zu erstellen oder Schnittstellen zu erzeugen die zwei inkompatible Objekte verbindet. Teile eines oder ganze Algorithmen wärend der Laufzeit auszutauschen und Objekte in Abhängigkeit zu stellen.


Und nun könnt ihr mich von mir aus in der Luft zereissen ;D

Zitat von »"Osram"«

Ist doch interessant, von drei Leuten hier sehen drei eine unterschiedlichen Haupt-Sinn in OO. Patrick sieht das Wiederverwerten, Du siehst die Schnittstellen und das Algo tauschen und ich sehe Bugvermeidung/Debugging/Erweiterbarkeit des Codes.

Ja ist schon lustig OO ist aber auch so vielseitig.

Zitat von »"Osram"«

Wozu ist z.B. protected, private etc da, wenn nicht zur Bug-Vermeidung? Kapselung auch und auch zur Fehlersuche: Wenn ich alle Informationen, die ein Objekt betreffen auf einen Blick habe, uU mir der Compiler sogar garantiert, dass das alles ist, finde ich den Bug schneller. Wenn ich noch Design by Contract nehme, sagt mir der Rechner, dass ich einen Fehler gemacht habe und wo ungefähr. Und schmale und standardisierte Schnittstellen helfen z.B. auch, Laufzeittests einzubauen .

Hmm...sicherlich stellt eine Kapselung eine Möglichkeit dar Bug's zu vermeiden. Schließlich kann man die Bug's in der Kapselung Elemnieren. Sollten dann noch Bug's vohanden sein ist man sicher das die in der Kapselung schon einmal nicht sind. Für die Erkennung von Fehlern kann man eh nie genug Hilfsmittel haben. Aber das kleine Rechtesystem (public, private, etc. mit der Vererbung) wurd wohl nicht dafür gemacht um Bugfreier zu Programmieren. Ich denke der Zweck ist wohl eher der das man bestimmen kann auf welche Eigenschaften der User zugriff haben darf und auf welche nicht. Das schließt vererbte Eigenschaften mit ein.
Sicher. In einem haste Recht. Man kann damit auch gleichzeitig verhindern das der User mit Sensiblen Daten schindluder treibt und man so in gewisser hinsicht Bug's vorbeugen kann.

Zitat von »"Osram"«

Ich habe von einem kommerziellen Spiel, welches von einem erfahrenem Team geschireben wurde und verkauft wurde, die Bug Statistik gesehen (Zahl bekannter Bugs aufgetragen über Zeit, vorausgesagte Zahl, absolute Zahl bei Verkauf). Absolut ernüchternd .

Das glaub ich gern. Aber kein Wunder. Wenn ein Programm so groß wird, kann es einfach nicht 100% Bug-Frei sein. Vor allem weil die meisten großen Programme auch noch mit mehreren Thread's arbeiten. Was die Bug-Suche nicht grad erleichtert.