Wann kommt neues OpenGL?

volkard

Original erstellt von KXII:
es kommt bei oo programmierung nicht darauf an, wie man die funktionalität hinschreibt, oder wie das, was hingeschrieben wurde zu deuten ist. ob man "stirb()" schreibt oder "leben=0", es hat keinen einfluss darauf, ob man nun oo programmiert oder nicht, denn sowas ist in einer strukturierten sprache möglch, oder auch in einer oo oder auch selbst in assembler (wie auch immer man diese sprachtyp bezeichnet). mann kann mit assembler eine funktion schreiben die "stirb" heisst, man kann aber auch eine funktion schreiben die "setleben" heisst, und nur weil man "stirb" benutzt heisst das noch lange nicht das die eigentliche programmierweise des ganzen programms objektorientiert ist. es kommt auf die relativen beziehungen von code und daten an, und wenn diese so angeordnet sind, das sie gruppen bilden, und funktionalität kapseln, dann spricht man von einer objekt-orientierten weise, eben weil man "objekte" als sortierkriterium genommen hat und nicht die reine strukturierung. man kann ja schliesslich auch mit assembler oo programmieren, nur man sieht das nicht so deutlich wie in hochsprachen. es mag zwar sein, das ein "stirb" schöner aussieht und in bezug auf die reale welt besser zu verstehen ist, es hat aber keinen einfluss auf die art der programmierweise. man darf oo auch nicht so "humanisiert" betrachten und alles was man programmiert aus unserer realen welt ableiten. das macht vielleicht oft sinn, es ist aber nicht immer möglich und ist auch nicht zwingend nur damit man oo programmiert.

jo.
(und auf die erwähnte offizielle definioon von oo bin ich ja sehr gespannt.)

[ Dieser Beitrag wurde am 30.06.2003 um 01:52 Uhr von volkard editiert. ]

Gregor

Da: http://www.galileocomputing.de/glossar/gp/anzeige-8975/FirstLetter-O

Programmierung, die nicht wie in der klassischen strukturierten Programmierung Algorithmen und Datenstrukturen getrennt voneinander entwirft, sondern von Objekten ausgeht, die beides in sich vereinen.

Stimmt also im Prinzip mit dem Text von KXII überein.

BTW: Lustig: KXII will objektorientiert ohne die OO-Sprachfeatures programmieren und ich nutze die Features, programmiere aber nach der obigen Definition alles andere als objektorientiert.

[ Dieser Beitrag wurde am 30.06.2003 um 03:13 Uhr von Gregor editiert. ]

Sgt. Nukem

Original erstellt von <kubikwurzelsuppe>:
stimmt. KXII hat recht. oop geht viel weiter [...] sehr diffus!

Kann'et sein daß Du keine Ahnung hast und Dich hier nur profilieren willst?? :p

Original erstellt von <xZumWürfel>:
KXII hat recht!!!
ich habs grad mal durchgerechnet!!!
es stimmt wirklich!!

Scheiße, den Gag wollte ich g'rade machen...

Original erstellt von <MEISTER DER MNEMONICS>:
**@Killing me Softly

[qb]Objektorientiertheit hat aber nix mit der sinnvollen Gruppierung von Funktionen und Variablen zu tun**

AUTSCH![/QB]

Das muß in der Tat weher tun als meine Zahnschmerzen...! (...und das heißt schon was!!) :o

[qb]...Ein Objekt hat keine Variablen und Funktionen sondern es hat Eigenschaften und besitzt ein Verhalten

also wenn ein objekt keine variablen und funktionen hat, dann bezieht sich deine sichtweise von objekten lediglich auf REALEXISTIERENDE objekte. da stimmt das natürlich und ich verstehe [...] [/QB]

Natürlich kann ein Objekt auch NUR "Eigenschaften" (Member-Variablen) oder NUR "Verhalten" (Member-Methoden) haben...!
Ich denke mal, das meinte er auch so...
Natürlich kann ich nicht immer 1:1 Objekte (besser: Dinge) der realen Welt als Objekttypen abbilden...

Original erstellt von KXII:
@Saugie
ich sehe die problematik aber aus der sicht des rechners, so wie die struakturen intern tatsächlich sind und dort wird sehr deutlich, was es heisst, wenn man quellcode richtig strukturiert und richtig klassifiziert. und da ist die bedeutung von syntax (->semantik) als alleiniges kriterium einfach nicht ausreichend um objekte zu definieren.

Ähhh... also diese "Objektorientierung" dient eigentlich *NUR* dem Menschen, dem Programmierer, der das Dingen codet, da Menschen nun mal von Natur aus in "Objekten" denken...
Dem Computer is' dat scheißegal! Du könntest auch 1 Millionen Befehle an Quellcode in eine Zeile quetschen oder besagtes "for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);" compilieren, da spielt der sich nich' am Pipimann für...

[...] und genau diese erfahrungen lassen mich sehr wohl wissen was es heisst, wenn man den aufbau von quellcode an objekten orientiert. man kann die definition natürlich auch noch weiter ausbauen, aber der grundgedanke, der gleibt immer gleich. ich bin mir ganz sicher, daß das was ich sage nicht frei erfunden ist, sondern sich aus erfahrung herauskristalisiert hat und offensichtlich ist.

Jo, das seh' ich auch so.
Bei großen Programmier-Vorhaben ist die gute alte strukturierte Programmierung einfach fehl am Platze. Zu fehleranfällig, zu unrobust, ...
Für kleinere Sachen natürlich noch immer nicht ersetzbar.

Ein ähnliches Verhalten durchläuft ja jetzt auch die Shadersprache (wenn auch viel schneller und unspektakulärer): Eigentlich waren's 'n Haufen von ASM-Befehle, und um's dem Menschen verständlicher zu machen, wurden HighLevel-Sprachen wie Cg oder HLSL entworfen... (hat jetzt nix direkt mit OO zu tun)

Original erstellt von Gregor:
BTW: Lustig: KXII will objektorientiert ohne die OO-Sprachfeatures programmieren und ich nutze die Features, programmiere aber nach der obigen Definition alles andere als objektorientiert.

Was sind denn die "OO-Sprachfeatures"?? Naja, Vererbung wird er wohl auch benutzen, etc. ...
Du nutzt Vererbung und Polymorphie OHNE OO?? Wie'n das??

KXII

@sgt. nukem

Ähhh... also diese "Objektorientierung" dient eigentlich *NUR* dem Menschen, dem Programmierer, der das Dingen codet, da Menschen nun mal von Natur aus in "Objekten" denken...
Dem Computer is' dat scheißegal! Du könntest auch 1 Millionen Befehle an Quellcode in eine Zeile quetschen oder besagtes "for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);" compilieren, da spielt der sich nich' am Pipimann für...

so wie du es darstellst war es von mir nicht gemeint. aber eigentlich müsstest du dir das doch denken können. es sollte nur verdeutlichen, das ich es von "unten" her betrachte, und mir eben diese sichtweise die beudetung von oop klarer macht. ich wollte NICHT sagen, das es einzig und allein nur drauf ankommt und sonst nichts. das wäre dann ja falsch.

Gregor

Original erstellt von Sgt. Nukem:
**
Du nutzt Vererbung und Polymorphie OHNE OO?? Wie'n das?? **

Das bezog sich auf "Datenstrukturen und Algorithmen in Objekten vereint".

An vielen Stellen trenne ich Datenstrukturen und Algorithmen ganz explizit. Die Algorithmen sind dann selbst Objekte und die entsprechenden Klassen liegen weder in der gleichen Datei noch im gleichen Verzeichnis. Naja: Das ist wohl ne Frage der Sichtweise. Man kann es trotzdem als OOP ansehen.

[ Dieser Beitrag wurde am 30.06.2003 um 13:26 Uhr von Gregor editiert. ]

Helium

meine darstellung bezieht sich auf OO im ALLGEMEINEN sinne. deine darstellung bezieht sich nur auf einen ganz, ganz kleinen bereich, der oo programmierung zu mehr ausdruck verhelfen KANN, aber absolut nichts mit dem GRUNDKONZEPT zu tun hat. oder willst du etwa sagen, das wenn man auch nur eine einzige funktion hat, die einen parameter hat, man nicht mehr oo programmiert? was ist denn wenn es ein onjekt gibt, das so etwas wie "stirb()" gar nicht kennt, oder bei dem nur ein "stirn(3)" sinn macht. dann wäre ja nach deiner defnition dieses objekt nicht mehr oo programmiert. aber das ist doch totaler schwachsinn. bevor du hier nochmal postest, dann bring erst mal deine definition von ALLGEMEINER oop und schwafel hier keinen scheiss, der obendrein auch noch falsch ist!

Die Anzahl der Parameter hat absolut nichts mit oo zu tun, auch wenn meine Erfahrung zeigt (nicht nur mit eigenem Quellcode), dass in der objektorientierten Programmierung viele Funktionen wenige Parameter besitzen. Funktionen ohne Parameter kommen in der strukturierten Programmierung nur äußerst selten vor.

also wenn ein objekt keine variablen und funktionen hat, dann bezieht sich deine sichtweise von objekten lediglich auf REALEXISTIERENDE objekte. da stimmt das natürlich und ich verstehe auch ganz ganu was du damit meinst. aber es gibt auch sowas wie abtrakte objekte, die mit der realen welt nicht zu vereinbaren sind. wie sollen diese denn aufgebaut sein, wenn sie nur eigenschaften und verhalten haben? das ist wie eine lehre hülle. etwas ohne kern. "eigenschaften" ist doch nur ein anderes wort für "variablen" und "verhalten" ein anderes wort für "methoden" (um nicht zu sagen funktionen). es gibt auch objekte die nur aus variablen bestehen, was ist denn dann mit denen? ein punkt zum beispiel.

In einer doppelt verketete Liste hat jedes Element einen Vorgänger und einen Nachfolger. Das sind Eigenschaften. Wenn du mir eine realexistierende doppelt verkettete Liste besorgen kannst bekommst du 100€ von mir.

wenn "dingsda.setLeben(0);" nicht objektorientiert ist, was ist es denn dann?

Es mag sein, das dingsda.setLeben(0) objektorientiert ist. Ich kenne die definition von Dingsda nicht, weiß vor allem nicht, was ein dingsda ist. Tut mir leid. Falls dingsa ein Lebewesen repräsentieren soll, ist es falsch. Und daruaf willst du ja hinaus.

Beispiel: Ich habe letztens (ist schon was her) eine physikalische Simmulation geschrieben. Es ging Um Gravitation. Mehrere Planeten sollten um eine Sonne kreisen.
Ich denke wir sind uns einig, dass wir wärend der OOA darauf kommen, dass es irgendwo in unserem System eine Klasse Planet geben wird. Die Klasse besaß nun ein Objekt position, welches vom Typ Punkt war. Das hätte dein Planet vermutlich auch gehabt. Was unsere Planeten unterscheidet ist folgendes: Dein Planet, so vermute ich, besitzt die Methoden set_position() und get_position(). Meiner besaß zwar auch ein get_position(), aber kein set_position(), was, wenn ich dich richtig einschätze, ür dich völlig absurd ist. Aber man kann einen Planeten nicht einfach durch die gegend beamen (selbst bei Star Trek hat das noch keiner geschaft). set_position() kann somit niemals eine eigenschaft von Planet sein.
Und siehe da trotzdem funktioniert meine Simulation perfekt. Falls du jetzt denkst, es gäbe etwas vergleichbares zu set_position() nur unter anderem Namen, dann irrst du dich. Es gab nur die dinge, die ein echter Planet auch kann, bzw. hat. Und das ist kein Wunder. In der Natur funktionier es ja auch.

Die Kunst bei der OOP, wenn es denn eine ist, ist es die Natur der wenn auch föllig abstrakten Objekte zu verstehen.

Und nochwas OOP wurde nicht für den Computer entwickelt worden, sondern für den Menschen. Der Computer käme mit Assembler wesentlich besser klar, auch wenn die Mnemonics immer noch zu umständlich sind. So muss er es sich vorher alles übersetzen.

Nur für KXXI:
Da du es ja so toll fandest, mit dem Alter, mit welchem du angefangen hast zu programmieren, zu protzen: Ich hab mit 11 meine ersten Programme geschrieben. Sorry.

Sgt. Nukem

Original erstellt von KXII:
so wie du es darstellst war es von mir nicht gemeint. aber eigentlich müsstest du dir das doch denken können. es sollte nur verdeutlichen, das ich es von "unten" her betrachte, und mir eben diese sichtweise die beudetung von oop klarer macht. ich wollte NICHT sagen, das es einzig und allein nur drauf ankommt und sonst nichts. das wäre dann ja falsch.

Aha...

Original erstellt von Gregor:
**Das bezog sich auf "Datenstrukturen und Algorithmen in Objekten vereint".

An vielen Stellen trenne ich Datenstrukturen und Algorithmen ganz explizit. Die Algorithmen sind dann selbst Objekte und die entsprechenden Klassen liegen weder in der gleichen Datei noch im gleichen Verzeichnis. Naja: Das ist wohl ne Frage der Sichtweise. Man kann es trotzdem als OOP ansehen.**

Ich versteh' Dich nicht genau...

"Klassen" liegen nicht in der gleichen Datei!?! Naja, das ist ja auch eine andere Ebene! Das müssen sie ja gar nicht.
Um genau zu sein KÖNNEN Klassen auch gar nicht in einer Datei liegen. Klassen sind nur imaginär. Existieren nur in unseren Köpfen. Genau wie Objekte.
Für C++ oder eine andere Programmiersprache mußt Du die Klassen halt nur irgendwie beschreiben.
Da bastelt man den deskriptiven Part meistens in eine Header-Datei, und den eigentlichen implementierenden in eine Quellcode-Datei.
Oder was meinst Du?!

Original erstellt von Helium:
Es mag sein, das dingsda.setLeben(0) objektorientiert ist. Ich kenne die definition von Dingsda nicht, weiß vor allem nicht, was ein dingsda ist. Tut mir leid. Falls dingsa ein Lebewesen repräsentieren soll, ist es falsch. Und daruaf willst du ja hinaus.

"Falsch" isset schonmal gar nicht. Höchstens nicht objektorientiert...

Meiner besaß zwar auch ein get_position(), aber kein set_position(), was, wenn ich dich richtig einschätze, ür dich völlig absurd ist. Aber man kann einen Planeten nicht einfach durch die gegend beamen (selbst bei Star Trek hat das noch keiner geschaft). set_position() kann somit niemals eine eigenschaft von Planet sein.

Aber bei Star Wars wurde zumindest einer zerfetzt. Hat Dein Planet denn das Verhalten bomb_away() ??

Aber um Dein Gesagtes vielleicht noch ein bisserl besser zu erklären, ein Beispiel aus dem Schach:

Die Klasse Turm hätte keinen Operator "AufFeldSetzen(std::string)".
Denn ich kann (darf) einen Turm im Schach nunmal nicht willkürlich auf irgendein Feld setzen (z.B. Turm->AufFeldSetzen("H3"); )!
Stattdessen würde es höchstens einen Operator "ZiehenAuf(std::string)" geben. Dem könnte ich besagtes "H3" übergeben, und der würde dann check0rn, ob besagter Zug möglich ist (Turm darf ja nur orthogonal ziehen / Feld muß frei sein / etc.), wenn ja -> wird der Zug ausgeführt / wenn nein -> halt nicht (z.B. exception, oder false als Rückgabe, o.ä.)!

Und nochwas OOP wurde nicht für den Computer entwickelt worden, sondern für den Menschen. Der Computer käme mit Assembler wesentlich besser klar, auch wenn die Mnemonics immer noch zu umständlich sind. So muss er es sich vorher alles übersetzen.

Klar wie Klo-Brühe mein lieber...

Nur für KXXI:
Da du es ja so toll fandest, mit dem Alter, mit welchem du angefangen hast zu programmieren, zu protzen: Ich hab mit 11 meine ersten Programme geschrieben. Sorry.

Krass. Mit 11 hatte ich noch Angst im Dunkeln und hab' Bravo gelesen...

Killing me softly

Warum dürfen Methoden in OO keine Parameter haben?
Keine Ahnung, dies hat KXII als Gegenargument aus dem Hut gezaubert und ich hab keinen blassen Schimmer, woher er das hat. Selbstverständlich dürfen Methoden Parameter besitzen *kopfschüttel*

Eigenschaften/Verhalten versus Variablen/Funktionen
Nehmen wir ein real existierendes Objekt - einen Stuhl. Ein Stuhl hat gewisse Eigenschaften (Material, Sitzhöhe, Gewicht etc.). Nehmen wir weiterhin an, ich schreibe eine Anwendung in der ich besagte Objekte in irgend einer Form verwalten will/muss/soll. An irgendeiner Stelle im Programm benötige ich die Information, ob sich besagter Stuhl im Wohnzimmer befindet. Jetzt gibt es zwei Möglichkeiten.
Programmierer A, der eine Klasse/Objekt nur als Sammelsurium von Variablen und Methoden versteht, wird keine Probleme haben einfach der Klasse ne neue Variable 'm_fStehtImWohnzimmer' zu spendieren. Er braucht die Information an dieser Stelle, es ist bequem, und außerdem hat er schon x Jahre Erfahrung und braucht sich deswegen keinerlei Gedanken zu machen.
Programmierer B, der eine Klasse/Objekt eben nicht nur als Sammelsurium von Variablen/Methoden versteht, wird sich überlegen, ob 'StehtImWohnzimmer' wirklich eine Eigenschaft von 'Stuhl' ist und realativ schnell feststellen. Nöö.
Also hat diese Variable auch nix in der Klasse 'CStuhl' zu suchen. Ergo muss er sich eine andere Lösung einfallen lassen. Vielleicht bracht er 20min. länger als Programmierer A (der die Zeit schonmal dazu genutzt hat, weitere Variablen in die Klasse zu integrieren wie 'm_fStehtImFlur', 'm_fStehtImSchlafzimmer', 'm_fStehtAufDerTerrasse').
Falls Programmierer B dieses Vorgehen konsequent einhält, und sich bei jeder Erweiterung der Klasse 'CStuhl' fragt, ob es sich wirklich um eine Eigenschaft bzw. um ein Verhalten eines Stuhles handelt, wird der erzeugte Code garantiert rubuster gegen Änderungen sein (spätestens, wenn Programmierer A mitbekommt, das ein Mehrfamilienhaus auch mehrere Wohnzimmer hat, werden bei ihm die Panikpickel sprießen). Weiterhin erhöht sich die reale Chance, das seine Klasse auch in anderen Projekten Verwendung finden kann, da die Klasse nicht mit anwendungsspezifischen Müll vollgestopft ist.
In diesem Zusammenhang ist vielleicht der Satz "Objektorientiertheit hat aber nix mit der sinnvollen Gruppierung von Funktionen und Variablen zu tun" besser zu verstehen. Wenn ich Variablen und Funktionen in mehr oder weniger sinnvollen Gruppen zusammenfasse, dann führe ich eine funktionale Aufgabenteilung durch. In der OOP (so wie ich sie verstehe) geht es aber nicht um "Aufgabenteilung in Funktionen" sondern um die Organisation von Verantwortungen. Daher ist ein Objekt mehr als nur eine Zusammenfassung von Variablen und Funktionen.

In meiner täglichen Arbeit sehe ich einfach, das es viel zu viele Programmierer der Kategorie A gibt, die ohne auch nur 5 sec. zu überlegen eine Klasse erweitern, und deren Klassenhierarchie (falls man das so nennen kann) bei der kleinsten Anforderungsänderung in sich zusammen fallen.
Was mit realen Objekten wie einem Stuhl funktioniert, das funktioniert übrigens genauso mit abstrakten Objekten.
Eine weitere Sache, die mir immer wieder negativ auffällt (und nicht wirklich dem OO-Gedanken entspricht) ist die Tendenz, Objekte von Außen zu manipulieren, anstatt die Objekte selbst agieren zu lassen (Verhalten versus Methode). Aus diesem Grunde benötigt die Simulation von Helium auch keine set_position()-Methode, da die Planeten eben nicht von Außen durch eine übergeordnete Instanz (Manager) manipuliert werden sondern selber agieren. Hierzu ist es logischerweise notwendig, das Objekte miteinander kommunizieren (was mittels Methoden, die selbstverständlich auch Parameter besitzen können, erfolgt). Randbemerkung: und falls es doch besagte Methode geben sollte, ist das kein Indiz dafür, das er nicht objektorientiert programmieren würde, nur um etwaige Argumentationen der Kategorie "Methoden dürfen keine Parameter besitzen" vorzubeugen.

Auch wenn es zweifelhaft bis kritisch ist, OO an einer einzigen fiktiven Programmzeile zu messen, die vollkommen alleine ohne jeden Kontext da steht, hol ich unseren alten Bekannten 'held' wieder aus der Schublade.
held_leben = 0; // autsch
held.leben = 0; // Objekt wird von Außen manipuliert und riecht für mich nach funktionaler Aufgabenteilung (was eher das genaue Gegenteil von OO ist), soll heißen: es gibt eine übergeordnete Instanz, die in diesem Falle über Leben und Tod entscheidet. Wir haben einen Manager (besagte Instanz) und einen Gemanagten (unseren Helden). Auch nicht viel besser.
held.strib(); // Es wird schon besser, nur zu mittelhohen Luftsprüngen mit pausenlosem Juhu-Geschrei reicht es noch nicht.
held.TakeDamage(10); // Eine Instanz (ein anderes Objekt) kommuniziert mit unserem Helden und sagt ihm 'ich füge dir Schaden zu'. Wie unser Held sich daraufhin verhält ist seine Sache (unter Umständen fällt er einfach um und ist Tod). Der grosse Unterschied zu den oberen Zeilen ist, das es keine übergeordnete Instanz gibt, welche unseren Helden (direkt) manipuliert. Unser Held agiert bzw. reagiert selber und wird nicht gemanagt.

Nachsatz
Da KXII seine Biographie zum besten gegeben hat, kann ich mir folgendes einfach nicht verkneifen (man möge mir bitte verzeihen): Ich bin 37 Jahre alt, habe mit 16 angefangen zu Programmieren. Zuerst in Basic und relativ schnell dann in C. Während meiner Ausbildung habe ich einen klitzekleinen Abstecher zu Pascal, COBOL und Assembler gemacht und bin vor 11 Jahren bei C++ hängen geblieben. Aufgrund 21-jähriger Programmiererfahrung (davon 15 Jahre beruflich) kann ich ohne Bedenken und mit viel Selbstvertrauen sagen, dass ich soweit fortgeschritten bin, um zu erkennen, das meine Lernphase nie abgeschlossen sein wird und keine angehäufte Erkenntnis so stark manifestiert ist, das sie nicht in Frage gestellt werden könnte, egal durch was (Artikel in Fachzeitschriften, Bücher oder im Netz) oder durch wen (John Carmack oder einem 16-jährigen Member hier im Forum). Und genau das finde ich so faszinierend.

KXII

@helium

man, du hast mir gerade mein bewustsein erweitert! danke! ich habe grade deine theorie durchgerechnet, und du hast tatsächlich recht! nicht zu fassen! alles macht plötzlich einen sinn. wie konnte ich nur so blind sein. es liegt doch auf der hand. was du gesagt hast ist nichts als die wahrheit. immer war es richtig. und ich idiot habe es nicht gesehen. ich hoffe du kannst mir verzeihen.

also nochmals:

ENTSCHULDIGE BITTE! SORRY, FÜR ALLES WAS ICH DIR ANGETAN HABE! ES WIRD NICHT WIEDER VORKOMMEN!

KXII

cpt.oneeye

Meiner besaß zwar auch ein get_position(), aber kein set_position(), was, wenn ich dich richtig einschätze, ür dich völlig absurd ist. Aber man kann einen Planeten nicht einfach durch die gegend beamen (selbst bei Star Trek hat das noch keiner geschaft). set_position() kann somit niemals eine eigenschaft von Planet sein.
Und siehe da trotzdem funktioniert meine Simulation perfekt. Falls du jetzt denkst, es gäbe etwas vergleichbares zu set_position() nur unter anderem Namen, dann irrst du dich.

@helium, killing me softly
Heisst das das sich die Planeten immer nur die Information mittels getFunktionen von anderen Planeten holen (z.b. von der Sonne um die die Planeten kreisen) und daraus ihre eigene Position selber bestimmen/berechnen?

Kann nicht z.b. ein schwarzes Loch die Funktion planet1.setPosition() aufrufen? Schliesslich beinflusst ja das schwarze Loch den Planeten und zieht den Planeten zu sich her und verschluckt ihn dann schlussendlich? Die Verantwortung liegt dann beim Loch! Das Loch wird aktiv und sagt ich verschlucke jetzt den Planeten und ziehe in zu mir her sprich ich verändere seine Position.

Nachtrag:
Hmm...ah ich glaub ihr meint das so

SchwarzesLoch{
private:
int m_distance;

void lookForPlanets(...){
if(planet1.getPosition <= m_distance)
  planet1.getInfluenced(vector direction); 
  // also das schwarze loch setzt nicht die position des planeten, sondern
  // sagt nur das es den planeten zu sich herzieht. ob der planet dann auch
  // zum loch kommt bestimmt er selber. der planet könnte sich ja dagegen wehren
  // (eher unwahrscheinlich *g*).
}
}

[ Dieser Beitrag wurde am 01.07.2003 um 02:01 Uhr von cpt.oneeye editiert. ]

Killing me softly

Ich weis zwar nicht wie Helium das gemacht hat, aber ich würde es folgendermaßen realisieren:
Frage: ist es wirklich die Aufgabe eines Schwarzen Loches, einem Planeten zu sagen, wie er sich zu verhalten hat? Antwort: nein, es liegt klar in der Verantwortung des Planeten. Der Planet kann ohne Probleme die Position und deren Masse der anderen Himmelskörper abfragen und daraus die auf ihn wirkende Gravitation und hiermit seine Flugbahn berechnen (ein Schwarzes Loch ist ja auch nur ein Himmelskörper, nur mit ner verdammt großen Masse).

Das Beispiel ist übrigens gut. Nehmen wir an, die Simulation ist fertig programmiert und zum Schluss kommen wir auf die Idee, wir könnten ja auch Raumschiffe in unserem virtuellen Weltall fliegen lassen. Welcher Änderungsaufwand ist hierfür notwendig? Bei meiner Lösung muss die Simulation nicht angepasst werden, das einzige was ich brauche ist eine neue Klasse CRaumschiff. Würden die Himmelskörper aber wie in deiner 2. Variante von Außen manipuliert werden, dürfte man alle Klassen durchgehen und entsprechend ändern.

Und damit hätten wir auch gleich den großen Vorteil einer sauberen OO-Programmierung demonstriert - sie ist relativ unempfindlich gegenüber nachträglichen Änderungen/Erweiterungen.

[ Dieser Beitrag wurde am 01.07.2003 um 13:34 Uhr von Killing me softly editiert. ]

[QB]Und damit hätten wir auch gleich den großen Vorteil einer sauberen OO-Programmierung demonstriert - sie ist relativ unempfindlich gegenüber nachträglichen Änderungen/Erweiterungen.[QB]

Das ist doch TRIVIAL!

Das trifft genauso für strukturierte Programme zu!

KXII

@Killing me softly

freut mich zu wissen wie alt du bist und wieviel erfahrung du hast. ich finde das verbessert die kommunikation, weil man weiß mit wem man es zu tun hat.

ABER:

deine extrem lange ausführung mit den drei überschriften, zeigt, daß du das problem absolut nicht kappierst. deine argumente sind lediglich NICHTS ANDERES als UNTERSTELLUNGEN und ANNAHMEN, und haben mit der definition allgemeiner OOP oder genauer gesagt, mit dem beweis, daß das was ich sage falsch ist, ASBOLUT NICHTS ZU TUN. um nur eines deiner bescheuerten beispiele zu nennen:

ich muss hoffentlch nicht beweisen, das "programmierer A" ein programmierer nach meiner definition ist. ich glaube das geht deutich aus dem text hervor.

**Programmierer A, der eine Klasse/Objekt nur als Sammelsurium von Variablen und Methoden versteht, wird keine Probleme haben einfach der Klasse ne neue Variable 'm_fStehtImWohnzimmer' zu spendieren. Er braucht die Information an dieser Stelle, es ist bequem, und außerdem hat er schon x Jahre Erfahrung und braucht sich deswegen keinerlei Gedanken zu machen.

Programmierer B, der eine Klasse/Objekt eben nicht nur als Sammelsurium von Variablen/Methoden versteht, wird sich überlegen, ob 'StehtImWohnzimmer' wirklich eine Eigenschaft von 'Stuhl' ist und realativ schnell feststellen. Nöö.
Also hat diese Variable auch nix in der Klasse 'CStuhl' zu suchen. Ergo muss er sich eine andere Lösung einfallen lassen. Vielleicht bracht er 20min. länger als Programmierer A (der die Zeit schonmal dazu genutzt hat, weitere Variablen in die Klasse zu integrieren wie 'm_fStehtImFlur', 'm_fStehtImSchlafzimmer', 'm_fStehtAufDerTerrasse').
**

alles unterstellungen; entspringen aus deiner programmirerefantasie, so wie du das programmieren siehst, es hat aber nichts mit der realität zu tun und auch nichts mit einer SINNVOLLEN und AKZEPTABLEN darstellung, die einen erkennen lässt, "ach ja, da ist ja wirklich was dran. meine darstelung sollte ich nochmal überdenken."

woher nimmst du dir die freiheit einfach sagen, das aus meiner argumentation automatisch auch deine oben aufgeführten darstellungen folgern? nur weil bei meiner definition alle darstellungsmöglichkeiten von methoden die objektorientierte programmierung nicht ausschliessen, heisst das doch noch lange nicht, das meine objekte automatisch schlecht designt sind, und ich ihnen deshalb automatisch funktionen verpasse, die gar nicht für sie bestimmt sind und die nichts mit dem objekt zu tun haben! warum sollte ich einem stuhl methoden verpassen, die einen kuchen backen oder ein auto waschen oder jemanden das essen bringen? warum sollte das so sein? HÄ? DENK darüber nochmal nach! ausserdem hat das eine mit dem anderen nichts zu tun.

hier werden die unterstellungen ganz deutlich:

...Er braucht die Information an dieser Stelle, es ist bequem, und außerdem hat er schon x Jahre Erfahrung und braucht sich deswegen keinerlei Gedanken zu machen.

*HAHAHAHAHA*

warum BRAUCHT er diese informationen an dieser stelle, wenn er nach meiner definition programmiert? er braucht sie NICHT!

warum ist es nur dann bequem wenn er nach meiner definition programmiert? es ist IMMER bequem müll zu programmieren!

warum braucht er sich keine gedanken darüber zu machen, wenn er nach meiner definition programmiert? man muss sich immer gedanken über das machen, was mann programmiert!

alle drei teilsätze sind unterstellungen und helfen dir nur, anderen, die den text nicht genau gelesen haben, den nachfolgenden text glaubhafter anzuerkennen, weil ja vorher was da gestanden hat, was offensichtlich falsch war. *tzzzz*

lebensalter hin, lebensalter her, deine programmiererfahrung hin oder her, das spielt keine rolle, wenn du nicht erkennst worum es eigentlch geht. mich wundert es, das du so unlogische ausführungen bringst. möchtest du absichtlich unglaubhaft sein? das kann ich mir nicht vorstellen.

du kannst bestimmt sehr gut programmieren und ich würde das auch niemals bestreiten. deine argumentationsweise in DIESEM POSTING ist aber extrem lächerlich! ich muss es so darstellen, weil ich wirklich nur noch darüber lachen kann, wie du und helium versucht zu argumentieren.

[ Dieser Beitrag wurde am 01.07.2003 um 16:18 Uhr von KXII editiert. ]

halt die Klappe, du unerfahrenes kiddie.

KXII

das mache ich auch, wenn mich jemand versucht zu ver*****en.

"auf die fresse kloppen" ist was für proleten.

[ Dieser Beitrag wurde am 01.07.2003 um 16:15 Uhr von KXII editiert. ]

"...kann ich ohne Bedenken und mit viel Selbstvertrauen sagen, dass ich soweit fortgeschritten bin, um zu erkennen, das meine Lernphase nie abgeschlossen sein wird und keine angehäufte Erkenntnis so stark manifestiert ist, das sie nicht in Frage gestellt werden könnte, egal durch was ..."

1.) lernphasen sind nie abgeschlossen. das ist trivial. jeder der arbeitet weiss das.

2.) man kann alles in frage stellen. dafür gibt es aber geeignete psychologische begriffe und es ist kein normales verhalten. ich habe mindestens 100 erkenntnisse, die ich als manifestiert betrachte. schade das du keine hast.

Harrison Bergeron

Original erstellt von <Giftzwerg>:
ich habe mindestens 100 erkenntnisse, die ich als manifestiert betrachte. schade das du keine hast.

Welche denn zum Beispiel?

Killing me softly

@giftzwerg:

Original erstellt von KXII:
...und ich kann ohne bedenken und mit viel selbstvertrauen sagen, dass ich soweit fortgeschritten bin, dass ich keine bücher mehr brauche, die mir die grundlagen des programmierens erklären!...

Original erstellt von KMS:
...kann ich ohne Bedenken und mit viel Selbstvertrauen sagen, dass ich soweit fortgeschritten bin, um zu erkennen, das meine Lernphase nie abgeschlossen sein wird und...

Vielleicht verstehst du jetzt den kleinen Seitenhieb in der Formulierung.

@KXII: Antwort kommt heute Abend, hab' gerade nicht die Zeit dazu.

KXII

lass gut sein. meine zeit ist zu kostbar.