Du bist nicht angemeldet.
Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
spieleprogrammierer.de »
Spieleentwicklung und Programmierung »
C, C++, C#, Java und andere Programmiersprachen »
04.09.2004, 08:57
Zitat
In meinem aktuellen Projekt war es mir auch sehr wichtig alles im OOD zu halten
und ja keine globale Variable,
keine defines usw.
Seit drei Tagen arbeite ich an professionellem Code oder sagen wir an Code eines kommerziellen Spiels und ich war erstaunt in wie Weit dort vom OOD abgewichen wird.
), Quake 2, Nolf, Freelancer, mit Einschränkungen HL2 und F4.
Nach dieser Erfahrung muss ich meine OOD Philosophie wirklich überdenken und vielleicht lieber "wohl überlegt" an die Sache gehen, als einfach auf einem Design zu pochen, was mehr schlecht als Recht ist.
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
. Man muss die Regeln die es gibt selber kritisch hinterfragen. Und man muss im Einzelfall nochmal hinterfragen, ob die Regel an der Stelle Sinn macht.
04.09.2004, 22:43
Übertrieben ja. Aber die meisten kann man sehr leicht umgehen. Das Prob an globalen Variablen ist das es sehr schnell unübersichtlich werden kann.
Gar keine? Das ist übertrieben.
Das sehe ich auch so. Allerdings kann man durch Templates und echten Konstanten (keine #define - Konstanten) eine bessere Typ-Sicherheit erreichen.
Ok, ich weiss, dass ich jetzt total gegen den Strom schwimme, aber ich sehe defines nicht als übel an. Immer schön viele Klammern setzen und man ist auf der sicheren Seite.
Nur wenn er gut ist. Hab schon den ein oder anderen Code gesehen und ich muss sagen das die alle sehr schlecht zu lesen waren. Von Kommentaren oder Dokumentation keine Spur. Und die Struktur ist auch sehr oft nicht grad die beste.
Von welchem, wenn man fragen darf? Ich weiss nicht von vielen kommerziellen Spielen, deren Source verfügbar ist: BoB, MA, EECH (alle von Empire ), Quake 2, Nolf, Freelancer, mit Einschränkungen HL2 und F4.
Dadurch erlangt man aber viele Vorteil, wie sichere Initialisierung, schnelleren Zugriff auf Komponenten usw.
Kenne zwar das Buch nicht aber ich glaub es dir auch so
"Netzwerkzugriff muss transparent sein" - Ich habe erst vor kurzem einen Verriss dieser "heiligen Regel" von einem Top-programmierer (Joel Sponsky) gelesen.
Gerade bei dingen wie die Netzwerkprogrammierung ist ein Transparenter Code einfach ein musss. Da man hier so Arbeiten muss als würde man mit mehreren Threads Arbeiten.
04.09.2004, 23:04
Übertrieben ja. Aber die meisten kann man sehr leicht umgehen. Das Prob an globalen Variablen ist das es sehr schnell unübersichtlich werden kann.
Das sehe ich auch so. Allerdings kann man durch Templates und echten Konstanten (keine #define - Konstanten) eine bessere Typ-Sicherheit erreichen.
Aber manchmal gibt es einfach nichts besseres. Z.b. bei der Automatischen Erstellung einer Exception.
Nur wenn er gut ist. Hab schon den ein oder anderen Code gesehen und ich muss sagen das die alle sehr schlecht zu lesen waren. Von Kommentaren oder Dokumentation keine Spur.
.
Kenne zwar das Buch nicht aber ich glaub es dir auch so
15.09.2004, 09:43
M.E. sollten alle Programme OO sein bis auf sehr sehr kleine.
15.09.2004, 12:55
.
Allerdings verstehe ich das jetzt nicht. Warum sollten funktionale oder logische Vorgehensweisen schneller zu Bugs führen, als eine objektorientierte?
In der Regel sind funtkionale Programme bei dem gleichen Algorithmus deutlich kürzer und übersichtlicher und gewinnen dabei sogar an Ausdrucksstärke.
, da der Compiler Dinge abchecken kann.
Solch ein Code lässt sich leichter lesen und besser warten.
Und wenn man so ein mächtiges Typ-System hat, wie beispielsweise in SML kann das auch nur von Vorteil sein. Und solche System findet man bisher nur in funktionalen oder Mischsprachen (ich meine funktional/oo).
Oder logische Sprachen. Wenn der Compiler für mich nachdenkt ist das doch sicherlich nur von Vorteil, wenn es ums vermeiden von Bugs geht, denn irren ist Menschlich.
OO als Allheilmittel zu verkaufen ist IMO falsch.
Es ist schön für gewisse Dinge, aber nicht generell perfekt.
.
Jedes Paradigma hat eine gewisse Berechtigung, auch wenn sie beim prozeduralen Programmieren vielleicht nur die ist, in gewissen Situationen das letzte Quäntschen Geschwindigkeit herauszuquetschen.
15.09.2004, 13:10
16.09.2004, 10:39
Es gitb auch Klassen, die sich selber testen.
Das kommt u.a. von dem mehr an Deklarationen in OO.
|
Quellcode |
1 2 |
let map funktion [] = []
map funktion (head::tail) = (funktion head :: map funktion tail)
|
|
|
C-/C++-Quelltext |
1 2 3 4 5 6 7 8 |
template <typename T, typename F> std::list<T> map (std::list<T> const & list, F f) { std::list<T> result; for (std::list<T>::const_iterator it=list.begin(); it!=list.end(); ++it) result.push_back (f(*it)); return result; } |
|
|
Quellcode |
1 |
let mul x y = x * y |
|
|
C-/C++-Quelltext |
1 2 3 4 5 |
tempalte <typename T, typename U> typeof(T() * U()) mul (T x, U y) { return x * y; } |
Ich empfinde OO als deutlich übersichtlicher als Funktionale Programmierung, da eben in einer Klasse alles zusammenghörige beieinander steht.
Fragen wir mal anders rum: Welche reine OO Sprache hat ein schlechtes Typsystem?
Dann frage ich mal, warum die so selten eingesetzt werden.
Das macht vielleicht für 5% des Codes Sinn. Und der ist evtl schon in einer Memberfunktion und muss nur "intern" schnell sein. Aber ich habe ja auch gesagt, dass man Teile eines Programmes weiterhin Funktional lassen kann.
16.09.2004, 12:25
Also, C'- und D'toren sind nichts, was durch die OO erzwungen wird. in Objective-C muss ich beispielswiese den C'tor manuell aufrufen, ich kann es also vergessen (zumindest theoretisch) und Objective-C ist IMHO "objektorientierter", als z.B. C++.
D'toren gibt es in den wenigsten OO-Sprachen.
Aber normalerweise schreibt man extern sogenannte Unit-Tests.
Entschuldige, in dem Fall habe ich mich total beschissen ausgedrückt. Die meisten OO-Sprachen sind dynamisch Typisiert, wie z.B. Smalltalk, Objective-C, Python, ... . Fehler werden erst zur Laufzeit gefunden.
Ich weiß es natürlich nicht wirklich. Aber ich nehme mal an, dass ein punkt ist, dass das logische Programmieren noch so neu ist.
Prozedural programmieren wir schon immer, funktional seit den fünfzigern.
Das klingt ja so, als würdest du das funktionale (SML, Haskell, ...) und das prozedurale (BASIC, Pascal, C, ...) Paradigma durcheinanderwürfeln.
04.05.2024, 03:03
Zum Seitenanfang
