Wann kommt neues OpenGL?
-
-
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 soSchwarzesLoch{ 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. ]
-
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!
-
@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.
-
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.
-
Original erstellt von <Giftzwerg>:
ich habe mindestens 100 erkenntnisse, die ich als manifestiert betrachte. schade das du keine hast.Welche denn zum Beispiel?
-
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.
-
lass gut sein. meine zeit ist zu kostbar.
-
@Sgt. Nukem: Dir war unklar, was es mit den Datei und Verzeichnissen im Zusamenhang mit Klassen auf sich hat. Dazu musst du wissen, das Gregor Java programmiert. Und da spielt die Aufteilung in Verzeichnisse, etc. eine Rolle. Es ist also etwas Javaspezifisches. Das nur zum Verständlnis.
"Falsch" isset schonmal gar nicht. Höchstens nicht objektorientiert...
Entschuldige meine ungenause Ausdrucksweise ich meinte Falsch im Sinne der Objektorientierung.
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?
Wie kommst du darauf? Das ist völlig absurdes Zeug. es kann doch durchaus von Interesse sein, wo der Stuhl steht und darum ging es.
1.) lernphasen sind nie abgeschlossen. das ist trivial. jeder der arbeitet weiss das.
Das heißt ich lerne immernoch zu gehen. Ich dachte das könne ich bereits.
@KXII: Bevor ich jetzt irgendwelche Mutmaßungen darüber anstelle, wie du programmierst, könntest du nicht einfach zu Demonstrationszwecken eine deiner Klassenhirachien zeigen. Am besten wäre ein einfaches UML-Diagram.
Meine und Killing me softlys vorgehensweise kennst du ja nun.
BTW, ich habe auchmal ähnliche Ansichten vertreten wie du. deswegen kenne ich beide Seiten. Du hast wie du es nennen würdest "meine Art der OOP" hingegen noch nicht probiert. Vielleicht solltest du das, bevor du ein Urteil fällst, mal tun.
-
"Das heißt ich lerne immernoch zu gehen. Ich dachte das könne ich bereits."
JUPP!
du kannst es, musst es aber immer weiter lernen. wenn du 10 jahre nicht gehen würdest dann hättest du es verlernt. wenn du 10 jahre kein english mehr sprechen würdest, dann hättest du es verlernt. wenn du 10 jahre keinen kuchen mehr backen würdest, dann hättest du es verlernt.
aber es gibt auch noch eine andere perspektive:
man muss immer DAZULERNEN. gerade beim arbeiten ist das wichtig, damit man auch zukünftig leistung erbringen kann. aber auch beim gehen ist das wichtig. jemand der zwar gehen kann, aber noch nie einen marathon gelaufen ist, der wird schnell merken, das man da die richtige gangart braucht um schneller zu sein als andere. oder jemand der noch nie geklettert hat, der wird merken, das seine füße erst noch lernen müssen den richtigen tritt zu finden, um auf dem felsboden standhaft zu sein. oder wenn du auf dem mond spazieren gehen würdest, dann müsstest du das auch erst lernen.
[ Dieser Beitrag wurde am 02.07.2003 um 01:11 Uhr von KXII editiert. ]
-
ich numeriere meine klassenamane durch, das macht sie berechenbarer als mit asciizeichen. also:
class 1000
{
};oder
class 2000
{
};
und hirachien gibt es bei mir erst gar nicht. alles ist public und dadurch gleichberechtigt. achja, zeiger und goto's sind hauptbestandteil meiner algorithmen.
[ Dieser Beitrag wurde am 01.07.2003 um 20:11 Uhr von KXII editiert. ]
-
Wo bleiben die kryptischen Makros, wilden Casts (wer braucht schon virtual?) und
inline asm?
Das muß man als guter Programmierer können, nein LIEBEN![ Dieser Beitrag wurde am 01.07.2003 um 22:18 Uhr von Kane editiert. ]
-
Original erstellt von KXII:
du kannst es, musst es aber immer weiter lernen. wenn du 10 jahre nicht gehen würdest dann hättest du es verlernt. wenn du 10 jahre kein english mehr sprechen würdest, dann hättest du es verlernt. wenn du 10 jahre keinen kuchen mehr backen würdest, dann hättest du es verlernt.Naja, gehen verlernt man nicht.
Einige Sachen sind ja auch angeboren...
@KillingMeSoftly: Sicher, daß Dir irgenein Artikel oder der John Deine manifestierte Meinung streitig machen können, daß 1 + 1 = 2 ist...?!?
-
Original erstellt von Sgt. Nukem:
**Naja, gehen verlernt man nicht.
**probiers doch mal und setz dich 10 jahre innen rollstuhl
-
Auf die existentiellen Fragen, ob 1+1 wirklich immer 2 ist und ob man die menschliche Fähigkeit auf zwei Beinen zu laufen durch kontinuierliche Konditionierung beliebig Perfektionieren kann, möchte ich an dieser Stelle nicht eingehen; das überlasse ich lieber anderen
@KXII: In meinem ersten Post habe ich u.a. von 'Eigenschaften' und 'Verhalten' gesprochen, ohne näher zu spezifizieren, was ich darunter verstehe bzw. wieso ich diese Begriffe der üblichen Benennung (Variablen/Methoden) vorziehe. Dies hat (zu Recht) dazu geführt, das meine Ausführungen teilweise falsch verstanden worden sind. Der Abschnitt war also primär dazu gedacht, besagte Begrifflichkeiten bzw. Aussagen zu klären (deswegen auch die dicke fette Überschrift) und weniger, dich oder deine Programmierkunst in irgend einer Weise zu diskreditieren.
Randbemerkung: an dieser Stelle möchte ich auch betonen, das der Grad an objektorientiertem Design innerhalb eines Programmes kein Mass für die Qualität des Programmes oder den Fähigkeiten des Programmierers ist. Wenn man sich bspw. den Quake-Source ansieht, dann springt einem extrem Hardcore-C entgegen; nix was nur annähernd nach OO aussieht und ich glaube kaum, das es hier jemanden gibt, der Klein-John als Pfuscher betiteln würde. Wollte ich einfach mal loswerden.
Was mich an deiner Definition von OO stört (oder besser: mit der ich nicht Komform gehe) ist folgendes:
...bei OO geht es doch darum, funktionalität in sinnvolle gruppen zu packen...
...die FUNKTIONALITÄT die dahinter steckt ist in allen fällen die selbe...Wenn du es so meinst, wie du es gesagt hast, dann sprichst du von einer "funktionalen Aufgabenteilung", dies entspricht aber dem klassich prozeduralen Paradigma. Die OO geht aber vom genauen Gegenteil aus, nämlich der "Aufgabenteilung nach Verantwortung". Da sich darunter kaum jemand im ersten Moment etwas vorstellen kann, hier mal ein Beispiel außerhalb der Programmierung.
Eine Firma besteht logischerweise aus verschiedenen Abteilungen. Bei der klassichen Aufteilung gibt es bsp. einen Einkauf, einen Vertrieb, eine Konstruktion, eine Produktion, einen Versand, eine Marketingabteilung u.s.w.. In diesem Falle spricht man von 'Funktionaler Organisation' d.h. jede Abteilung hat eine bestimmte Funktion (logisch). Der Einkauf hat die Funktion, Teile zu beschaffen; die Produktion hat die Funktion, aus den Einzelteilen das fertige Produkt zu bauen; das Marketing hat die Funktion, Werbung zu machen und so weiter.
Man kann seine Firma aber auch komplett anders organisieren. Eine Möglichkeit ist die Abteilungen nach Produktgruppen zu unterteilen (divisionale Organisation), d.h. die einzelnen Abteilungen sind für ein bestimmtes Produkt bzw. Produktgruppe o.ä. verantwortlich. In so einer Abteilung tummeln sich dann Konstrukteure, Vertriebler, Werbefritzen u.s.w.. Bei einer solchen Organisation ist z.B. die Gefahr, das die Konstruktion was "erfindet" was kein Mensch gebrauchen kann und der Vertrieb deswegen die Sachen nicht unters Volk bringt bzw. der Vertrieb den Kunden das Blaue vom Himmel verspricht, das so nie und nimmer produziert werden kann (und wenn doch, dann nicht für den Preis), nicht so stark gegeben (dafür gibt's andere Probleme).Es gibt also mehrere Möglichkeiten ein großes System zu organisieren. Die geläufigste ist nach Funktionen; eine andere währe z.B. nach Verantwortungsbereichen.
Zurück zur Programmierung: Auch bei der Programmierung ist es notwendig eine Organisation aufzubauen d.h. das System in überschaubare Bereiche aufzuteilen. Auch hier kann die Teilung nach funktionalen Gesichtspunkten erfolgen (klassisch prozedurales Paradigma). Die OOP geht aber einen anderen Weg. Hier geht es (ich wiederhole mich) um die Organisation von Verantwortlichkeiten. Die Funktionalität des daraus aufgebauten Programmes entsteht so gesehen erst im zweiten Schritt, nämlich durch das Zusammenspiel der Objekte und nicht dadurch, das die Funktionalität selbst in Gruppen zusammengefasst, ne Klammer drumrum gesetzt und class davor geschrieben wird.