4. Wann kommt neues OpenGL?

Wann kommt neues OpenGL?

  • B

    In Smalltalk und CLOS sind Klassen auch Objekte.

    > (defclass foo () ())
#<Standard-Class FOO #xFFAAF0>

> (type-of (find-class 'foo))
STANDARD-CLASS
    0
  • K

    @helium

    ...Ein Objekt ist bereits eine Instanz und kann nicht mehr instanziert werden

    also ehrlich, glaubst du wirklich das ich das nicht wüsste??? 😕 !

    das ist eine sehr einfache und eingeengte sicht von dir, die auch sehr oft von anfängern gebraucht wird (ich hoffe du bist keiner). man sollte das nicht so "streng" sehen. ein objekt ist ein abtraktes gebilde im allgemeinen sinne; und ein instaziertes gebilde kann man auch als objekt bezeichnen, es ist aber nicht zwingend! warauf es ankommt ist zu unterscheiden zwischen der definition eines objektes und der instanzierung eines objektes. wie man diese zwei dinge genau bezeichnet ist nicht relevant. wichtig ist nur das andere wissen was gemeint ist. ich würde niemandem etwas vorwerfen, wenn er das nicht 100% korrekt ausdrückt. mann muss nicht unbedingt zu einem instanzierten "ding" objekt sagen. das ist das selbe, wie wenn man zu funktionen methoden sagen soll. das ist doch blödsinn sich auf solche kleinigkeiten zu beschränken.

    du hast geschrieben:

    **```cpp
    Ich sehe sofort, das das Instanzieren eines Typs absolut OOP-Typisch ist, da

    man weder in funktionalen noch struktorierten Sprachen Variablen verwendent.

    Denk darüber bitte nochmal nach. Das stimmt nämlich nicht so ganz.

    Der Unterschied leigt in folgendem:

    if (monster_x == held_x && monster_y == held_y) {
    held_leben = 0;
    spiel_beenden();
    }
    Nun erstelle ich doch mal schnell ein paar Klassen und denke ich könnte nun OO proggen.

    if (monster.x == held.x && monster.y == held.y) {
    held.leben = 0;
    spiel_beenden();
    }
    Und? Ist das OO? nicht wirklich.

    Versuchen wirs nochmal (natürlich verwenden wir wieder Klassen, aber etwas anders):

    if (monster.faeng(held)) {
    held.stirb();
    spiel_beenden();
    }
    Und tada. Selbst jemand, der nicht Progrmmieren, kann mit dem unteren fast was anfangen, wärend das obere eher nach Mathe aussieht.

    
wenn nur das letzte beispiel für dich OOte programmierung ist, ... naja ... ich hoffe es nicht!  

ich sehe das alles aus einer ganz anderen und viel abtrakteren perspektive. du beschränkst dich wieder auf kleinigkeiten.  

bei OO geht es doch darum, funktionalität in sinnvolle gruppen zu packen und zwar in einer form, die es erlaubt, instzanzen davon bilden zu können. man beschreibt diese gruppen (oft als klassen bezeichnet) und bildet objekte davon, die eine bestimmte lebenszeit haben. es gibt ein eindeutiges davor ein jetzt und ein danach. das ist im groben alles, und wie man es realisiert ist völlig egal. wichtig ist, das man von globalen variablen/objekte wegkommt, die IMMER existieren und nur EIN mal. man könnte es auch als individualisierung bezeichnen.  

der unterschied von  

held_leben = 0;  

und  

"held.leben = 0;"  

und  

"held.stirb();"  

liegt doch nur in der schreibweise.  

die FUNKTIONALITÄT die dahinter steckt ist in allen fällen die selbe. natürlich ist die dritte variante etwas besser gekapselt (das liegt aber nur an c/c++), weil man eine funktion aufruft und man dadurch eine INDIREKTE wertezuweisung ermöglicht, aber das ist doch absolut programmiersprachenabhängig oder anders gesagt designabhängig. man könnte genausogut der instanz "leben" von "held" einen zuweisungsoperator hinzufügen, der nichts anderes macht als eine funktion aufzurufen, die den wert dann indirekt zuweist. das ist dann das selbe (optisch gesehen) wie beim dritten beispiel. oder mann könnte es auch ganz anders machen; es gibt unendlich viele möglichkeiten um diese funktionalität zu realisieren und darzustellen.  

(ganz krass gesagt, man müsste es noch nicht einmal optisch darstellen. mann könnte es auch akustisch machen, mit einer sprache - einen entsprechenden computer und software vorausgesetzt. wäre das dann für dich NICHT mehr OO nur weil man die funktion nicht mehr sehen kann, und sie dadurch natürlich nicht mehr das aussehen wie in beispiel 3 hat?)  

ein einfacherer weg wäre es per "drag and drop" zu machen. das wäre auch OO, auch wenn nirgend steht "abc=blabla;" oder "abc(blabla)" oder sonstwas.  

[ Dieser Beitrag wurde am 27.06.2003 um 22:14 Uhr von **KXII** editiert. ]
    0
  • H

    OK, verdeutliche ich es etwas. ERsetze den zweiten Teil meines Beispiels durch folgendes. Der Text bleibt der selbe:

    if (monster.get_x() == held.get_x() && monster.get_y() == held.get_y()) {
   held.set_leben(0);
   spiel_beenden();
}

    Aussage von mir ist immer noch die selbe: Das ist nicht OOP. Das ist pseudogekapsele, das bis auf die Tatsache, das es mehr schreibarbeit ist nichts ändert. Es ist aber schonmal ein großer schritt, da das direkte Setzen der Position verhindert wird, da kein set_x bzw, set_y existiert.

    bei OO geht es doch darum, funktionalität in sinnvolle gruppen zu packen und zwar in einer form, die es erlaubt, instzanzen davon bilden zu können. man beschreibt diese gruppen (oft als klassen bezeichnet) und bildet objekte davon, die eine bestimmte lebenszeit haben. es gibt ein eindeutiges davor ein jetzt und ein danach. das ist im groben alles, und wie man es realisiert ist völlig egal.

    Man bezeichnet diese "Gruppen" immer als Klassen. Und jede Variable in jeder Sprache hat irgendeine Zeit wärend der sie existiert. Da hat nix mit OO zu tun.

    wichtig ist, das man von globalen variablen/objekte wegkommt, die IMMER existieren und nur EIN mal. man könnte es auch als individualisierung bezeichnen.

    Ach und bei der strukturierten. Ja aber das war in der struktorierten programmierung doch genauso. Man versucht alle Variablen lokal in Funktionen anzulegen. Bei manchen ging das nicht. die wurden dann global. Jetzt packst du Sie als statisches Element in eine Klasse oder bstelst ein Singleton drumherum. Technisch gesehen ist das doch das selbe.

    der unterschied von

    held_leben = 0;

    und

    "held.leben = 0;"

    und

    "held.stirb();"

    liegt doch nur in der schreibweise.

    Nein. Das hast du eben nicht verstanden. Die Schreibweise ist völlig egal. Es geht einzig und allein um die Semantik.

    0
  • K

    du hast geschrieben:

    "

    held_leben = 0;

    und

    "held.leben = 0;"

    und

    "held.stirb();"

    liegt doch nur in der schreibweise.

    Nein. Das hast du eben nicht verstanden. Die Schreibweise ist völlig egal. Es
    geht einzig und allein um die Semantik.

    "

    du beschränkst wieder OO-programmierung auf kleinigkeiten. die semantik ist in jeder sprache unterschiedlich und die syntax ist vollkommen irrelevant. 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.

    ich sehe es so, und ich kann auch nicht erkennen wo mein denkfehler liegen sollte. falls die klassische informatik objektorientierung anders definiert hat, dann wird es halt zeit für eine neue definition. da bin ich mir sicher. ich kann und will mich auf jeden fall nicht an die alten, klassischen definitionen halten!

    deshalb würde ich sagen: jedem seine meinung!

    0
  • ?

    In der guten alten prozeduralen Zeit gab es auf der einen Seite die dummen Daten und auf der anderen Seite die schlauen Funktionen, die mit den Daten irgendetwas gemacht haben. Viele sehen in der OO nix weiter, als eine Möglichkeit, besagte Daten und Funktionen in Gruppen zu ordnen. Objektorientiertheit hat aber nix mit der sinnvollen Gruppierung von Funktionen und Variablen zu tun.
    Ein Objekt hat keine Variablen und Funktionen sondern es hat Eigenschaften und besitzt ein Verhalten. Rein technisch gesehen ist das zwar das gleiche, vom gedanklichen Ansatz aber zwei vollkommen verschiedene Dinge.
    Ob ich nun 'held.leben = 0;' oder 'held.set_leben(0);' schreibe, ist vollkommen Banane. In beiden Fällen setzte ich eine Eigenschaft des Objektes. held.sterben() ist allerdings ein Verhalten und es ist Sache des Objektes und nicht des Aufrufers, welche Auswirkungen dieses Verhalten hat. Im einfachsten Falle fällt unser Held tot um. Genauso gut könnte er aber auch zum Zombie mutieren. Das Verhalten kann auch von Objekt zu Objekt unterschiedlich sein.

    Für alle, die zwischen 'held.leben = 0;' und 'held.sirb()' nur eine unterschiedliche Schreibweise erkennen empfehle ich mal die Lektüre "Objektorientierte Programmierung von Peter Coad, Jill Nicola"

    0
  • S

    Original erstellt von <Killing me Softly>:
    Ob ich nun 'held.leben = 0;' oder 'held.set_leben(0);' schreibe, ist vollkommen Banane. In beiden Fällen setzte ich eine Eigenschaft des Objektes. held.sterben() ist allerdings ein Verhalten und es ist Sache des Objektes und nicht des Aufrufers, welche Auswirkungen dieses Verhalten hat. Im einfachsten Falle fällt unser Held tot um. Genauso gut könnte er aber auch zum Zombie mutieren. Das Verhalten kann auch von Objekt zu Objekt unterschiedlich sein.

    Gut. Aber das Objekt könnte ja bei seiner Instanziierung auch einen eigenen Thread aufgemacht haben, und damit die ganze Zeit checken, ob leben == 0 ist, und wenn ja, DANN zu einem Zombie mutieren, oder einem Werwolf, oder Pamela Anderson...! 😉

    0
  • K

    @unregistrierter

    lies du deine lektüren. ich benutze mein gehirn.

    0
  • ?

    helium hat recht. 😮 😮 😮

    ich habs gerade mal durchgerechnet!!! 😮 😮

    😮 😮 😮

    0
  • S

    Muahahahahaha!! 😮 😃 :p

    0
  • H

    <Killing me Softly> hat die ganz offensichtlich die objektorientierte Programmierung an sich verstanden und weis deren Vorteile zu nutzen, wärend KXII OO nur als eine Art Sprachfeature sieht und im Grunde nix damit anfangen kann. Das heißt natürlich nicht, dass KXII schlechtere Programme schreibt, sondern nur, dass er Sie auf eine aus heutiger sicht leicht veralteten weise schreibt. Aber das soll uns nicht weiter stören.
    Und wenn wir jetzt nicht wieder zum Originalthema zurückfinden sollte das Thema bitte vom Moderator geschlossen werden.

    0
  • K

    @helium

    das ist eindeutig eine beleidigung.

    wenn hier jemand nicht versteht was objekt-ORIENTIERT heisst, dann du. und ich kann sehr wohl was damit anfangen. und ich glaube auch nicht dass ich meine programme auf eine veraltete weise schreibe. ich habe mindestens 10 argumente warum deine version schwachsinnig und falsch ist. ich habe aber keine lust sie dir darzustellen.

    um es auf den punkt zu bringen:

    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!

    0
  • ?

    stimmt. KXII hat recht. oop geht viel weiter als nur auf die schreibweise von funktionen beschränkt. eine solche schreibweise macht oop deutlicher, aber es ist kein konstituierendes element. ich glaube auch das das beispiel von helium zu einfach gewählt ist. das was KXII gesagt hat passt ganz gut. was passiert denn wenn das objekt keine funktion "stirb" hat, sondern nur eine funktion "stirb(long,long,float)" einfach weil das so ist, und es anders keinen sinn macht. ist es dann nicht mehr objektorientiert programmiert, nur weil die funktion andere parameter hat? wo liegt da genau die grenze? gibt es da überhaupt eine grenze? und wer legt sie fest? wenn jemand das sterben von objekten anders sieht oder anders definiert, dann soll er es auch so programmieren! ist es dann aber nicht mehr objektorientiert programmiert nur weil er es anders gemacht hat als mit deiner vsersion helium? ich glaube wenn man so "eng" versucht objektorientierteprogrammierung zu beschreiben, dann wird das ganze sehr diffus!

    0
  • ?

    KXII hat recht!!! 😮
    ich habs grad mal durchgerechnet!!! 😮 😮
    es stimmt wirklich!! 😮 😮 😮

    0
  • ?

    @Killing me Softly

    Objektorientiertheit hat aber nix mit der sinnvollen Gruppierung von Funktionen und Variablen zu tun

    AUTSCH!

    ...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 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.

    class CPoint
{
public:
  long X;
  long Y;
};

    ist das für dich ein objekt? ist das objekt-orientiert-programmiert? ich würde sagen ja. auch wenn es so alleine erst mal nichts anderes als eine datenstruktur ist. aber man kann dem objekt ja noch verhaltensweisen bzw. methoden hinzufügen. ist es dann wichtig wie diese methoden aussehen, nur damit es IMMER noch objekt-orientiert ist?

    //das ist also objekt-orientiert?

class CPoint
{
public:
  long X;
  long Y;

public:
  void stirb(void);
};

//das ist nicht mehr objekt-orientiert?

class CPoint
{
public:
  long X;
  long Y;

public:
  void stirb(long);
};

//das ist objekt-orientiert?

class CPoint
{
public:
  long X;
  long Y;

public:
  void stirb(void);
  void auferstehe(void);
};

//das nicht mehr objekt-orientiert?

class CPoint
{
public:
  long X;
  long Y;

public:
  void stirb(void);
  void auferstehe(long);
};

//das ist dann bestimmt öbszön

class CPoint
{
public:
  long X;
  long Y;

public:
  void stirb(long, long, long, long);
  void auferstehe(long, long, long, long);
};
    0
  • S

    Original erstellt von KXII:
    **@unregistrierter

    lies du deine lektüren. ich benutze mein gehirn.**

    Du denkst dir deine Definition von OOP selber aus und ein andere list es in einem Buch. Und du glaubst, dass das was du hier erzählst richtig ist? 😕

    Also IMO klingt das was killing me softly gesagt hat ganz vernünftig, hab aber, wie immer, keine Ahnung. 😉

    0
  • K

    @Saugie

    ich habe mir die definition von oop nicht ausgedacht!

    ich habe früher auch einmal mit büchern angefangen und ich habe früher auch bücher über oop gelesen und ich kann mich auch noch sehr gut an die kinderbeispiele errinern, die oft genommen wurden um oop zu erklären. wer aber auch nur einen hauch mathematischer erfahrung hat, der weiss, was eine definition ist und was ein beispiel ist. sollen doch diejenigen, die sich an beispielen orientieren, weiter an diesen orientieren. 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.

    ich programmiere jetzt schon über 9 jahre (ich bin 22 11/12=23, 23 - 9 = 14, habe also mit 14 angefangen), und ich habe, neben vielen anderen sprachen, vorwiegend mit assembler und c/c++ programmiererfahrung sammeln können. 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! 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.

    so, jetzt ist aber gut.

    soll mich doch der teufel holen!

    😡

    0
  • ?

    😡 😡 😡 😡

    @helium

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

    😡 😡 😡 😡

    0
  • V

    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. ]

    0
  • G

    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. ]

    0
  • S

    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?? 😕

    0
Anmelden zum Antworten