Objektorientierung - Eine Fehlentwicklung der Informatik?

[Steffen]

Hi,

würde mich mal die allgemeine Stimmung zu diesem Thema interessieren.

Hat der Verfasser recht?

Grüße, Steffen

[Peter Nack]

Hallo,

ja, er hat recht: Er persoenlich mag keine Objektorientierung.

Womit er sonst noch recht haben kann, erschlieszt sich mir nicht, da neben der Polemik keine Argumente geliefert werden.

MfG
Peter

[hotti]

moin,

Hat der Verfasser recht?

Ja. Objektorientiert programmieren heißt Einschränken.

Und zwar auf das Wesentliche.

Z.B. wenn es darum geht, Schnittstellen zu programmieren, da geht es im Wesentlichen darum, abstract Layer voneinander klar zu trennen.

Rolf

[Stefanie]

Hi,

der vermischt da Sachen, die so nicht direkt was miteinander zu tun haben und er verallgemeinert Erfahrungen, die ich so nicht bestätigen kann.

Klar hat er recht damit, dass sich in viele Softwareprojekten zu Tode geplant wird und nachher ein zu großes zu unflexibles Sytem heraus kommt, was der Kunde so gar nicht will und was nicht rechtzeitig fertig wird.

Daraus aber zu schiessen, man müsste nur das programmieren, was allgemein als  "quick and dirty" bezeichnet wird und alles wäre gut, ist in meinen Augen Humbug. Da sind ganz einfach andere, leichtgewichtigere Ansätze von Softwareprojektierung nötig, agile z.B. Auch dort gilt durchaus auch als ein Grundprinzip: Keep it small and simple.

Das kreative Austoben der einzelnen Entwicklers muss da einfach Grenzen haben, wo man in großen Teams und hohen Sicherheitsanforderungen programmiert und jeder sich schnell in die Strukturen des anderen einfinden können muss. Das Problem ist auch gar nicht mal "quick and dirty" eine Software zu entwickeln, die irgendwie funktioniert, sondern das ganze als Mensch dauerhaft geistig durchdringen zu können, bei eigener und fremder Software. Ist dies nicht möglich, kommt es schnell zu Fehlern, die obendrein schwer gefunden werden können. Die Zeit, die man beim Designen und Programmieren gespart hat, handelt man sich hier drei mal wieder ein.

In der Embeddedentwicklung hat sich Objektorientierung größtenteils noch nicht durchgesetzt und ich sehe die Nachteile jeden Tag. Zudem finde ich es geradezu lachhaft, es als Alternative zu betrachten, ganze Softwarepakete mal eben(?) neu zu schreiben, wenn sie so verwarzt sind, dass man nichts mehr daran ändern kann. Auch bei Neuentwicklungen kann die Wiederverwendbarkeit von bestehenden Modulen genau die Zeiteinsparung bringen, die die Nase eine Handbreit vor die des Konkurrenten bringt. Nein, Software muss nicht generell leicht änderbar sein - sie sollte nur leicht erweiterbar sein. Und das liefert ein Objektorientierter Ansatz.

Interessiert hätte mich auch noch, wie er mit "quick and dirty" eine ähnlich gute Testabdeckung erreichen will, aber vielleicht wird er ja in seinem Buch konkreter. Sein Bild eines Softwareentwicklers der alleine in seiner Bude hockt und über Nacht eine innovativ funktionierende Software zaubert, ist mir allerdings ein Graus. Keine Teamarbeit, keine Kommunikation, keinen Plan, ja die Kollegen gibt es heute noch. Es sind aber genau die, durch deren Software nie wieder jemand durchsteigt und die einem richtig fiese und schwer zu findende (und manchmal auch richtig gefährliche) Fehler bescheren.

Nun, wie bei allem im Leben gibt es hier halt auch nicht nur schwarz und weiss.

Gruss
Stefanie

[hotti]

hi,

Klar hat er recht damit, dass sich in viele Softwareprojekten zu Tode geplant wird und nachher ein zu großes zu unflexibles Sytem heraus kommt,

Erstens ja, aber zweitens ist ja gerade OOP der Weg, die Projekte flexibel zu machen. Letzeres hab ich bei Eric Forster Johnson gelesen und kann das aus meiner Praxis voll und ganz bestätigen.

Beispiel ist meine Website, die objektorientiert aufgebaut ist, das war sie schon immer. Relativ neu ist, dass sie jetzt auch objektorientiert programmiert erstellt wird ;-)

Rolf

[Der Martin]

Hallo,

der vermischt da Sachen, die so nicht direkt was miteinander zu tun haben und er verallgemeinert Erfahrungen, die ich so nicht bestätigen kann.

er vermischt vor allem das Prinzip und den Zweck der Objektorientierung mit der realen Implementierung großer objektorientierter Applikationen oder Frameworks. Ich stimme mit ihm überein, dass ein komplexes objektorientiert geschriebenes Framework oft schwieriger zu durchschauen ist als eine klassische Bibliothek einzelner Funktionen, die klar voneinander abgegrenzt sind. Solche Frameworks wirken, wenn sie fertig sind, wie ein riesiges Wollknäuel mit Tausenden von Schlaufen, Ösen und Knoten.

Dabei ist die Absicht doch eher, überschaubare Module (eben Objekte bzw. Klassen) mit klar definierter Funktionalität zu haben.

Klar hat er recht damit, dass sich in viele Softwareprojekten zu Tode geplant wird und nachher ein zu großes zu unflexibles Sytem heraus kommt, was der Kunde so gar nicht will und was nicht rechtzeitig fertig wird.

Ja, leider ist das oft so.

Daraus aber zu schiessen, man müsste nur das programmieren, was allgemein als  "quick and dirty" bezeichnet wird und alles wäre gut, ist in meinen Augen Humbug.

Klar, das ist völliger Unsinn.

Das Problem ist auch gar nicht mal "quick and dirty" eine Software zu entwickeln, die irgendwie funktioniert

Kommt auf die Zielsetzung an. Wenn ich irgendein Script, eine kleine Anwendung nur für den Eigenbedarf und nur für eine klar umrissene Aufgabe brauche, ist "quick & dirty" schon ab und zu okay.

In der Embeddedentwicklung hat sich Objektorientierung größtenteils noch nicht durchgesetzt und ich sehe die Nachteile jeden Tag. Zudem finde ich es geradezu lachhaft, es als Alternative zu betrachten, ganze Softwarepakete mal eben(?) neu zu schreiben, wenn sie so verwarzt sind, dass man nichts mehr daran ändern kann.

Kommt drauf an[tm]. Ich habe auch schon mehrmals erlebt, dass ich Stunden investiert habe, um den Code meines Vorgängers nachzuvollziehen, und dann habe ich's irgendwann aufgegeben und das Modul anhand der Spezifikationen und Anforderungen sauber neu geschrieben. Oder dass ich viel Zeit darauf verwendet habe, mich in die Klassenbibliothek einzuarbeiten, die jemand anders mir empfohlen hat, das Zusammenspiel der einzelnen Komponenten anhand der oft unbrauchbaren Dokumentation zu begreifen, die Beispiele nachzuvollziehen, bei deren Erklärung oft der entscheidene Schritt fehlt.
Das sind dann Situationen, wo das Neuschreiben eines übersichtlichen, leicht nachvollziehbaren Moduls günstiger sein kann, als den vorhandenen, aber konfusen Code um jeden Preis weiter zu verwenden.

Auch bei Neuentwicklungen kann die Wiederverwendbarkeit von bestehenden Modulen genau die Zeiteinsparung bringen, die die Nase eine Handbreit vor die des Konkurrenten bringt.

Ja. Setzt aber voraus, dass diese Module sauber gekapselt und dokumentiert sind. Da hapert's in der Praxis leider oft.

Nein, Software muss nicht generell leicht änderbar sein - sie sollte nur leicht erweiterbar sein. Und das liefert ein Objektorientierter Ansatz.

Einspruch: Leicht änderbar ist für mich ebenso wichtig wie leicht erweiterbar, das geht Hand in Hand. Wie oft hat man nicht Anforderungen "so ähnlich wie xyz, nur mit dem kleinen Unterschied, dass ..." Dann muss es möglich sein, das Modul xyz zu nehmen und die gewünschten Änderungen zielstrebig vorzunehmen und das Ganze nach entsprechender Verifikation vielleicht sogar als Variante von xyz für den Nächsten wieder ins Archiv zu legen.

Interessiert hätte mich auch noch, wie er mit "quick and dirty" eine ähnlich gute Testabdeckung erreichen will, aber vielleicht wird er ja in seinem Buch konkreter.

Ich glaube nicht.

Sein Bild eines Softwareentwicklers der alleine in seiner Bude hockt und über Nacht eine innovativ funktionierende Software zaubert, ist mir allerdings ein Graus.

Bis zu einem gewissen Grad passe ich auf dieses Schema, aber ...

Keine Teamarbeit, keine Kommunikation, keinen Plan [...] durch deren Software nie wieder jemand durchsteigt und die einem richtig fiese und schwer zu findende (und manchmal auch richtig gefährliche) Fehler bescheren.

... genau das darf nicht sein. Schnittstellen und Funktionsanforderungen müssen klar festgelegt sein; der resultierende Code leicht durchschaubar und wartbar, die Dokumentation für jeden mit entsprechendem Fachwissen verständlich.

Und um auf Andreas Orlik zurückzukommen: Mir scheint, er kritisiert (zu Recht) die herrschende Praxis objektorientierter Programmierung, ohne die zugrundeliegende (idealisierte) Theorie zu kennen.

So long,
 Martin

[hotti]

hi,

Und um auf Andreas Orlik zurückzukommen: Mir scheint, er kritisiert (zu Recht) die herrschende Praxis objektorientierter Programmierung, ohne die zugrundeliegende (idealisierte) Theorie zu kennen.

Also ich werde das Gefühl nicht los, dass um OOP genauson ähnlicher Rummel stattfindet wie um Web20, JSON oder jquery.

Und da ich OOP auch schon seit vielen Jahren kenne und nur dann praktiziere, wenn das Ergebnis als "Objekt" (*) modellierbar ist, kann ich manchmal nur den Kopf schütteln, wenn ich sehe, was manche so mit dem Schnee von gestern machen.

Nunja, ich philosophiere ja auch gerne, siehe mein neuer Artikel Kritik an der heutigen Browsergeneration und darin hab ich auch ein paar Worte zu json geschrieben.

(*) betrachte eine HTML-Datei als Objekt "URL", hierzu mein Konstruktor

  
package ContentBase;  
# Der Konstruktor für ein $cb-Objekt  
sub new{  
	my $self = shift;  
	my $url = shift;  
	  
	$self = {};  
  
	# Object Properties, alle bisher möglichen Eigenschaften, scalierbar!  
	$self->{URL} = $url;  
	$self->{TITLE} = undef;  
	$self->{DESCR} = undef;  
	$self->{PICS} = undef;  
	$self->{ORDNER} = undef;  
	$self->{TIME} = undef;   # Last-Modified  
	$self->{CONTENT} = undef; # cgi und php bleibt leer  
  
	bless $self;  
	return $self;  
}  

Dazu gesellen sich 2 ObjektMethoden, eine, die das Objekt mit Werten füllt wobei diese Werte (Attribute) direkt und ohne Umweg aus meiner Projektverwaltung kommen und eine zweite Methode, die beschreibt den Dateitransfer eines URL-Objects zum Webserver. Das nenne ich mal einen sinnvollen Einsatz von OOP, der Code vorher war mindestens 3 DIN-A4-Seiten länger und völlig unübersichtlich. Es gäbe sicher noch mehr Attribute für o.g. Verwendungszweck, beispielsweise /css oder /js oder auch charset und language, die sind bei mir jedoch alle gleich. Es wäre jedenfalls mit OOP kein Gewaltakt, weitere Attribute da einzubauen.

Rolf

[Sven Rautenberg]

Moin!

Nunja, ich philosophiere ja auch gerne, siehe mein neuer Artikel Kritik an der heutigen Browsergeneration und darin hab ich auch ein paar Worte zu json geschrieben.

Dieser Artikel ist im Prinzip in die Nähe des hier ebenfalls kritisierten OOP-Artikels einzuordnen. Vielleicht mit nicht ganz soviel Ahnungslosigkeit.

Nur mal diesen Absatz aus der Einleitung betrachtet und zerpflückt:

"Mit der relativ jungen Ajax-Technik kommen jedoch Fragen auf. Z.B. die Frage, warum es derzeit nicht möglich ist, ein multipart/form-data als Request zu schicken, was heutige Browser schon lange können."

Das ist möglich. Es ist nur viel aufwendiger zusammenzustricken, deshalb macht es niemand, weil man multipart/form-data bei Formularen nur __zwingend__ verwenden muss, wenn man Dateien mit hochladen will. Aber nichts in der Ajax-Implementierung hält dich davon ab, multipart/form-data zu senden.

"Oder die Frage, warum sollten die Encodings, die für POST und GET beschrieben sind, nur in eine Richtung gelten,"

Weil in der anderen Richtung eine Codierung nicht notwendig ist. Für solche One-Way-Codierungen gibts zahlreiche Beispiele, ich denke da nur an das Escaping für die Datenbank: mysqli_real_escape_string() für den Weg zu MySQL - kein De-Escaping auf dem Rückweg.

"warum sollte das DOM nicht in der Lage sein, aus der Response des Webservers einen Multipart Content zu parsen oder einen Querystring zu lesen?"

Das DOM nativ ist dazu nicht in der Lage, weil es gar nicht die Aufgabe des DOM ist. Wenn du unbedingt übermäßig codierte Nachrichten hin- und herschicken willst, steht es dir frei, das zu tun. Viel Spaß beim auseinandefriemeln. Wenn man sowas vermeiden kann - was man kann - dann wird man es vermeiden. XML ist die Variante, die man haben will, wenn man gerne DOM-Operationen anwendet. JSON ist die Methode, wenn man eher javascript-nah an die Daten will.

"Oder auch die Frage, warum sich Entwickler von Ajax-Anwendungen stets nur auf einen Request/Response beschränken, obwohl es bei den heutigen Breitbandanschlüssen durchaus die Möglichkeit gäbe, mehrere asynchrone Requests zu senden?"

Weil die Anzahl der parallel startbaren Ajax-Requests im Browser begrenzt ist.

"Und warum unterscheidet ein serverseitiger Parser GET-Daten von POST-Daten exclusiv, wo es doch die Möglichkeit gibt, sowohl GET-Parameter als auch Daten per POST gleichzeitig zu requesten bzw. per HTTP übertragen?"

Hä? Wer tut das? PHP jedenfalls nicht. Wenn dein geliebtes Perl in dieser Richtung scheitert... dein Pech. Einen Grund dafür gibt es nicht.

Im übrigen: Weil du es in deinem Artikel wieder diese data-URLs für Bilder anführst... die Reaktionen auf dein entsprechendes Forumsposting sind dir entgangen? Oder wurden sie ignoriert?

- Sven Rautenberg

[hotti]

moin Sven,

vielen Dank, es ist ein schönes Thema, mehr dazu weiter unten, doch zunächst:

Dieser Artikel ist im Prinzip in die Nähe des hier ebenfalls kritisierten OOP-Artikels einzuordnen. Vielleicht mit nicht ganz soviel Ahnungslosigkeit.

Von wegen *Vielleicht* ;-)

Weil die Anzahl der parallel startbaren Ajax-Requests im Browser begrenzt ist.

Asynchron heißt ja eben: Nicht parallel. Schau mal: Ich hab ne Strecke, die ist schmal(bandig) und was zu übertragen. Das geht da nur seriell, hintereinander, eben weil die Bandbreite das nicht hergibt. Heute jedoch hab ich Breitbandverbindungen und kann asynchron übertragen, d.h., ich schicke meine Datenpakete asynchron da rein, soviel wie eben reinpasst. Nicht gleichzeitig, nicht nebeneinander, sondern asynchron!

Zu OOP; Ja oder nein hänge ich an folg. Kriterium: Lässt sich das Produkt als Objekt modellieren, dann OOP, mein Beispiel von gestern.

Habe ich jedoch lediglich ein Modul zu schreiben, was Funktionen bereitstellt, brauche ich kein Objekt, nur um die Ausführung der Funktionen willen. Und hierzu noch ein Beispiel in Perl, das CGI.pm:

Wozu brauche ich ein Objekt, wenn ich lediglich die Funktion param() aufrufen will!? Hier ist OOP nicht angebracht.

Das Schöne an Perl ist, und deswegen liebe ich Perl; hier kann ich eine Klasse einbinden, wenn ich ein Objekt brauche, aber ich kann das Modul auch einbinden, wenn ich kein Objekt brauche.

Und so gibt es in Perl-Modulen neben dem Konstruktor auch Funktionen, die objektunabhängig sind.

Und noch ein schöner Streitpunkt, JavaScript: Wozu um Himmels Willen, brauche ich ein Objekt Date(), wenn ich nur die Zeitzone bestimmen will!?

Im Gegensatz zu Perl komme ich hier gar nicht an OOP vorbei ;-)

Naja, OOP, hin und her, es wäre für mich auch maln Stoff für einen Feuilleton Artikel, aber soviel hab ich nun dazu auch wieder nicht zu sagen oder zu schreiben, s.o., das ist im Prinzip schon alles.

Viele Grüße,
schönes Wochenende,
Rolf

[flowh]

Hallo hotti.

Asynchron heißt ja eben: Nicht parallel.

(A)Synchronität und Parallelität steht für mich in keinem Zusammenhang.

Wenn ich asynchron sende, dann schicke ich meine Nachricht ab, ohne auf ein Bestätigung zu warten. Mehr sagt asynchron nicht aus.
(Bei (A)Synchronität betrachte ich also eine einzelne Nachricht.)

Wenn ich parallel sende, dann sende ich zwei Nachrichten (mehr oder weniger) gleichzeitig, damit ist aber nichts über die Art des Sendens (asynchron oder synchron) ausgesagt.
(Bei Parallelität betrachte ich also auch mehrere Nachrichten.)

Ich sehe hier keinen Zusammenhang.

Wenn du mir den Zusammenhang zwischen Parallelität und Synchronität erklären kannst, dann bitte ich darum!

Servus,
Flo

[Sven Rautenberg]

Moin!

vielen Dank, es ist ein schönes Thema, mehr dazu weiter unten, doch zunächst:

...gehts du auf die Kritik an DEINEM Artikel gar nicht weiter ein.

Außer auf das hier:

Weil die Anzahl der parallel startbaren Ajax-Requests im Browser begrenzt ist.

Asynchron heißt ja eben: Nicht parallel.

Asynchron heißt asynchron.

Schau mal: Ich hab ne Strecke, die ist schmal(bandig) und was zu übertragen. Das geht da nur seriell, hintereinander, eben weil die Bandbreite das nicht hergibt. Heute jedoch hab ich Breitbandverbindungen und kann asynchron übertragen, d.h., ich schicke meine Datenpakete asynchron da rein, soviel wie eben reinpasst. Nicht gleichzeitig, nicht nebeneinander, sondern asynchron!

Bullshit! Auch eine breitbandige Verbindung überträgt die Daten seriell, daran hat sich nie etwas geändert. Und auch eine schmalbandige TCP/IP-Verbindung kann mehrere Requests des darüberliegenden HTTP-Protokolls ineinander gemischt übertragen. Das hat mit Asynchronität absolut nichts zu tun.

Wikipedia meint: http://de.wikipedia.org/wiki/Asynchrone_Kommunikation - das ist das, was wir beim XMLHttpRequest haben.

Außerdem: http://de.wikipedia.org/wiki/Asynchrone_Datenübertragung - das ist das, was ggf. auf der Übertragungsleitung passiert. Ist aber etwas ganz anderes.

- Sven Rautenberg

[ChrisB]

Hi,

Und noch ein schöner Streitpunkt, JavaScript: Wozu um Himmels Willen, brauche ich ein Objekt Date(), wenn ich nur die Zeitzone bestimmen will!?

Das ist kein üblicher Anwendungsfall; im Normalfall wirst du mit dem (aktuellen) Datum „mehr“ machen wollen.

Und deshalb sind die relevanten Methoden alle schön an einem Objekt gebündelt. Auch in diesem Falle ist der OO-Ansatz wesentlich sinnvoller, als zig Funktionen im globalen Space rumfliegen zu haben, die zwar alle was mit dem Datum zu tun haben, aber sonst in keinerlei Zusammenhang stehen würden.

MfG ChrisB

[Struppi]

"Und warum unterscheidet ein serverseitiger Parser GET-Daten von POST-Daten exclusiv, wo es doch die Möglichkeit gibt, sowohl GET-Parameter als auch Daten per POST gleichzeitig zu requesten bzw. per HTTP übertragen?"

Hä? Wer tut das? PHP jedenfalls nicht. Wenn dein geliebtes Perl in dieser Richtung scheitert...

Tut es nicht.

Struppi.

[dedlfix]

Hi!

"Und warum unterscheidet ein serverseitiger Parser GET-Daten von POST-Daten exclusiv, wo es doch die Möglichkeit gibt, sowohl GET-Parameter als auch Daten per POST gleichzeitig zu requesten bzw. per HTTP übertragen?"

Hä? Wer tut das? PHP jedenfalls nicht. Wenn dein geliebtes Perl in dieser Richtung scheitert...
Tut es nicht.

Oh doch, "sein geliebtes Perl" scheitert, weil der liebe hotti oft ganz eigene Auffassungen von der (Nicht-)Verwendung vorhandener Hilfsmittel hat.</erbsenzählend> Dass Perl mit dem entsprechenden Modul das auch hinbekommt, hattest du ja irgendwann schon mal dargestellt.

Lo!

[Tom]

Hello,

Nun, wie bei allem im Leben gibt es hier halt auch nicht nur schwarz und weiss.

So sehe ich das auch.

Allerdings bin ich hier auch schon oft genug für meine Meinung verlacht worden, dass OOP oft nur zum Selbstzweck, oder um als "modern" zu gelten, verwendet wird. Viele Dinge lassen sich klassisch imperativ viel schneller und sauberer lösen, insbesondere, wenn man die Fähigkeiten von Prozessorarchitekturen ausreizen will oder muss. Aber das sagtest Du ja schon :-))

OOP ist als Konzept mMn also durchaus keine Fehlentwicklung, wenn der Entwickler die _Möglichkeit_ hat, ab der tiefsten benutzten Klasse Eingriffe oder Änderungen vorzunehmen. Das reine Blackboxdenken ist hier mMn der Knackepunkt. In höhreren Schichten wird oft etwas nochmal entwickelt, weil man die Funktionsweise der tieferen nicht mehr kennt und auch nicht nachschauen kann, wie sie wirken, auch wenn man sie nicht antasten (ändern) will.

OOP entbindet keinen Entwickler davon, sich immer wieder mit dem Gesamtsystem auseinanderzusetzen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Peter Nack]

Hallo,

OOP ist als Konzept mMn also durchaus keine Fehlentwicklung, wenn der Entwickler die _Möglichkeit_ hat, ab der tiefsten benutzten Klasse Eingriffe oder Änderungen vorzunehmen.

In den tiefsten Schichten Aenderungen vorzunehmen sollte tunlichst vermieden werden.
Intervention wird ueber die Sichtbarkeit von Klassen und Methoden geregelt.

Das reine Blackboxdenken ist hier mMn der Knackepunkt. In höhreren Schichten wird oft etwas nochmal entwickelt, weil man die Funktionsweise der tieferen nicht mehr kennt und auch nicht nachschauen kann, wie sie wirken, auch wenn man sie nicht antasten (ändern) will.

Wer Libraries ohne Sourcen einbindet ist selbst schuld. Wer Libraries ohne Dokumentationen nutzt, ist noch schuldiger[™].
Und wenn etwas in einer hoeheren Schicht nochmal neu entwickelt werden muss, dann ist das schlicht und einfach dilletantisch programmiert.

OOP entbindet keinen Entwickler davon, sich immer wieder mit dem Gesamtsystem auseinanderzusetzen.

Hierfuer gibt es APIs. Das debuggen bis in die tiefsten Klassen eines Systems ist in nur sehr sehr seltenen Faellen noetig.

MfG
Peter

[Cheatah]

Hi,

würde mich mal die allgemeine Stimmung zu diesem Thema interessieren.

der Autor möchte kompensieren, dass er mit OOP nicht klar kommt. Der Artikel strotz vor Umformulierungen der Aussage "ich habe das nicht verstanden". Keine wirklich glaubwürdige Basis, um sich ein Absoluturteil leisten zu können.

Cheatah

[Steel]

Moin!

Der Tag heut geht ja lustig weiter...

Netter Artikel. Er hat eine schoene Liste gemacht, warum er OOP nicht mag. Untermauert hat er es nicht. Weiteres Stoebern auf der Seite ergibt weoterisches Gelaber von jemanden der sich scheinbar keinen Konventionen unterwerfen will, weil er sie nicht selbst entwickelt hat (weil er sie nicht versteht?). Manche nennen sowas kraetiv, kuensterlisch oder einen Freigeist. *lacht schmutzig*

Ein Programmierer der sich nicht in seiner Kreativitaet ausleben kann, weil er sich von Normen unterdrueckt fuehlt. Als Grafikkuenstler waere er vielleicht der Typ Art-Director der auch keine Kreise malen kann.

Teilweise mag er ja recht haben. Der geistige Flash von dem er spricht fuehrt in der Tat zu einem funktionierendem Code, der von einigen Leuten vielelicht sogar als genial angesehen wird. Dummerweise ist er normalerweise nur schwer erweiterbar, weil der Programmierer eben nicht alle oder eventuelle zukuenftige Eventualitaeten beruecksichtigt hat. Ich habe taeglich mit solchen Code zu tun, den ein "genialer Kollege"* (Mein Chef ist dieser Meinung) geschrieben hat. Allgemein kann ich aus meiner Erfahrung nur sagen, dass die Art der Programmierung, die er scheinbar vorschlaegt, viele Probleme bei der Wartung und Erweiterung verursacht. Entsprechend weiter programmiert fuehrt das schneller zur (langwierigen) Neuentwicklung eines Programms als eigentlich notwendig. Weil das aber nicht unbedingt mal eben moeglich ist (Zeit ist Geld), wird er Code irgendwie angepasst und laeuft weiter - was nicht selten zu Fehlern fuehrt. Falls man ueberhaupt merkt, dass der alte Code sich neuen Begebenheiten nicht anpasst und fleissig Fehler produziert. Genauer wissen wir wohl, was der Autor meint, wenn wir das Buch lesen. Das wird, in meinem Fall, aber wohl nicht passieren.

* der die Firma uebrigens wegen eines laengeren Aufenthalt im Landeskrankenhaus verlassen hat...

[Steel]

Das kommt davon, wenn man gleich morgens sowas liest...
Das Wort weoterisch soll esoterisch heissen. ;)

[Patrick Andrieu]

Hallo Steel!

Das kommt davon, wenn man gleich morgens sowas liest...
Das Wort weoterisch soll esoterisch heissen. ;)

Du bist ein Freigeist der Wortkreation:

Manche nennen sowas kraetiv, kuensterlisch oder einen Freigeist. *lacht schmutzig*

Viele Grüße aus Frankfurt/Main,
Patrick, manchmal auch krätiv, selten aber künsterlisch... ;)

[Steel]

Du bist ein Freigeist der Wortkreation:

*lacht* Du hast ja so recht. :D

[Don P]

Hallo,

Der geistige Flash von dem er spricht fuehrt in der Tat zu einem funktionierendem Code, der von einigen Leuten vielelicht sogar als genial angesehen wird. Dummerweise ist er normalerweise nur schwer erweiterbar, weil der Programmierer eben nicht alle oder eventuelle zukuenftige Eventualitaeten beruecksichtigt hat.

So sehe ich das auch, habe selber so "kreativ" angefangen als Autodidakt und das Ergebnis waren zwar immer irgendwie funktionierende Programme, die aber niemand außer mir durchschaute und ich selber bald auch nicht mehr.
Angefangen von Spaghetti-Code der schlimmsten Sorte fast ganz ohne eigene Funktionen (d.h. ohne Stuktur), über strukturierte Programme mit vielen separaten und wiederverwendbaren Prozeduren und Funktionen, bin ich inzwischen bei OOP angekommen und möchte es nicht mehr missen.

Man kann kleine Progrämmchen für einen begrenzten Einsatzzweck zwar trotzdem quick & dirty ohne Objekte zusammenpfuschen, aber für jedes halbwegs vernünftige Projekt, das erweiterbar und skalierbar sein soll, kommt man m.E. an OOP nicht vorbei.

Steinzeit? - Nein danke!

Gruß, Don P

[Gunnar Bittersmann]

@@Steffen:

nuqneH

würde mich mal die allgemeine Stimmung zu diesem Thema interessieren.

„Das erinnert mich sehr an meine Kindheit in der DDR, als auch nur bestimmte Arten des Denkens zugelassen waren.“

Jaja, und Meinungsfreiheit gab’s auch nicht. Ich möchte die Meinungsfreiheit jetzt nicht missen. Man sollte aber _sinnvoll_ mit ihr umgehen.

„Mir selbst ging es lange so, dass ich dachte, ich sei zu dumm für das Thema.“

An diesem Gedanken hätte der Autor vielleicht festhalten sollen.

Qapla'

[Encoder]

Da hat halt einer nicht kapiert wie man oo entwickelt und kriegt kein Buch drüber zustande. Jetzt zieht er sich eben geschwungene Sätze gegen oo aus der Nase, in der Hoffnung sie würden Sinn machen und jemand könnte sie verstehen und kauft das Buch.
Mal im Ernst, ich kapiert kaum etwas was da steht.
Dinge einfach so benennen wie sie sind, z.B. Datei... Was hindert ihn dran das zu tun?
Ein Programm wird auf mehrere *Dateien* aufgeteilt... Wird es ja tatsächlich, aber drückt das jemand so aus der ein bisschen Ahnung hat? Ein Auto wird auch auf verschiedene Bleche aufgeteilt. Eins vorne und bestimmt ist hinten auch noch eins. Vielleicht gibts sogar ein Mittelblech? :-)

Quick and dirty ist ne gute Sache, wenns schnell gehen soll. Aber der hat noch kein System entwickelt dass ein bisschen anspruchsvoller ist und auch nach Wochen noch nachvollziehbar ist.

[MudGuard]

Hi,

"Mir selbst ging es lange so, dass ich dachte, ich sei zu dumm für das Thema. Um das nicht zugeben zu müssen, tat ich immer schön so, als sei mir alles klar"

und tut immer noch so, als wäre ihm alles klar ...

"Für einfache Gemüter wie mich" + "Viel mehr Begriffe brauche ich nicht und kann ich mir auch nicht merken."

spricht auch nicht gerade für den Autoren.

cu,
Andreas

[Peter Nack]

He ho,

also wenn man sich mal ein wenig auf seiner Seite umschaut, so stoeszt man schon auf einige lustige Sachen.

Beispiel:
"Hinter der großen zeitraubenden Anstrengung, eine zukunftstaugliche Softwarearchitektur hervorzubringen, steht die Angst, eine Softwarearchitektur könne sich als ungeeignet herausstellen und dann muss man alles noch mal machen."

Und dann folgt:
"Wenn man immer den schnellsten, direktesten Weg geht, dann muss man von Zeit zu Zeit das System neu aufsetzen. Das ist aber kein Problem, weil das System extrem klein und schlank ist. Auf diese Weise erhält man mit der Zeit die richtig guten wirklich tragfähigen Softwarearchitekturen."

Ich glaube ich kaufe das Buch!

Und die Strafbarkeit homosexueller Handlungen hat mich auch schon immer interessiert.

Nicht ganz so ernst gemeinte Gruesze
Peter

[Bademeister]

Hi Steffen.

würde mich mal die allgemeine Stimmung zu diesem Thema interessieren.

"Stimmung" ist ein schoenes Wort dafuer. So viele Meinungen... ich hab auch eine:

Der Wert des Konzepts von Klassen und Objekten fuer die Programmierung kann m.E. kaum hoch genug eingestuft werden. Und ich vermute, dass es da kaum zwei Meinungen gibt (von Leuten, die eine echte Meinung darueber haben).
Der Begriff "Objektorientierung"[1] ist u.U. allerdings wirklich etwas problematisch. Aber: Wer sich "an Objekten orientiert"[1], ist, wenn ueberhaupt, der Programmierer[2]. Dann ist im Zweifelsfall klar, wo das Problem zu suchen ist.

Hat der Verfasser recht?

Weiss nicht recht. Das meiste hab ich nicht verstanden. Etwa bei

"Die begriffliche Vermischung, die ein direktes Mapping von Anforderungselementen auf Lösungselemente herbeiführen soll, stellt natürlich den Versuch dar, die kreative Lücke zu schließen und einen möglichst konstruktiven Übergang von den Anforderungen zur Lösung zu finden."

bin ich beim zweiten Komma bereits voellig abgehaengt.

Nein, mal ernsthaft:

Der Verfasser haette sich die Muehe machen muessen(!), hinzuschreiben, was Objektorientierung eigentlich bedeuten soll. Das ist naemlich keineswegs klar (ihm schon gar nicht, scheint es), und daher steht in dem Artikel *ueberhaupt*nichts* drin.

[1] Was immer das heisst.
[2] Sofern das Ganze nicht im Hinblick auf einzelne, konkrete Programmiersprachen zu verstehen ist.

Viele Gruesse,
der Bademeister

[jobo]

Hallo,

Referenzen auf andere Quellen gibt es ja scheints nicht. Also steht er mit seiner Meinung wohl recht alleine da.

Gruß

jobo

[Andreas Pflug]

würde mich mal die allgemeine Stimmung zu diesem Thema interessieren.

Hat der Verfasser recht?

Der Autor hackt zunächst mit sehr vielen - aber dadurch nicht unbedingt verständlicheren - Argumenten auf Objektorientierung herum. Konkrete Beispiele, die seine Argumentation untermauern, werden tunlichst vermieden. Den Vergleich von Objektorientierung mit einer Ideologie finde ich überzogen: Niemand hindert mich daran, auch heute noch Fortran77- oder Assemblerprogramme zu übersetzen oder kreativer Pointer-Arithmetik in C zu fröhnen. Ich würde Objektorientierung eher als einen Zusatz ansehen, der insbesondere dann Sinn macht, wenn komplexe Daten- und Programmsysteme (z. B. eine Benutzeroberfläche wie KDE) strukturiert werden sollen.

MfG

Andreas

[Edgar Ehritt]

Hallo Steffen,

würde mich mal die allgemeine Stimmung zu diesem Thema interessieren.

die allgemeine Stimmung sollte durch die anderen Kommentare hinreichend klar sein. Objektorientierung hat seine Berechtigung.

Hat der Verfasser recht?

Man sollte sich zuallererst fragen welchen Zweck der Artikel verfolgt. Schließlich haben wir es mit einen Diplom-Mathematiker zu tun. Analytisches aufbohren der Materie kann da nicht schlecht sein.

Was will also Andreas Orlik? Ein Buch verkaufen.
Womit macht man das am besten? Man wirbt für sein Werk.
Welche Werbung weckt Interesse? Nicht näher erläuterte Kontroversen gegen vorherrschende Meinungen/Stimmungen.

Wie auch immer Objektorientierung ist nur eine Abstraktion. Die CPU sieht, ob nun mit Objekten oder ohne programmierte wurde, nur eine Folge zweier Zustände, die sich mit 0 und 1 abstrahieren lassen. Da angekommen ist jede Debatte pro und kontra OOP Des Kaisers Neue Kleider. ;)

Gruß aus Berlin!
eddi

[Tom]

Hello,

würde mich mal die allgemeine Stimmung zu diesem Thema interessieren.

Hat der Verfasser recht?

Es gibt hier wohl kein schwarz/weiß oder "Recht haben".
Eine substantiierte Betrachtung im Einzelfall ist notwendig.

OOP ist ohne passende Entwicklungsumgebung nicht sehr sinnvoll, wenn auch trotzdem möglich. Ich habe das schon zu Assemblerzeiten versucht und bin dann alsbald an die Grenzen des Machbaren gestoßen, weil es ungeheuer aufwändig ist, die jeweiligen Rahmenbedungungen "zu Fuß" einzustellen und zu überprüfen.

Man benötigt also Unterstützung dafür. Diese wird durch die IDE geleistet. Ist die IDE mächtig, liefert sie auch gleich eine Klassensammlung mit. Diese schränkt dann die Freiheit des Entwicklers ein. Hinzu kommt hier auch meistens die mMn falsche Vorgabe der freien Portierbarkeit, die im Falle von z.B. C++ zu einer extrem mangelhaften Unterstützung der äußerst gängigen Plattform Intel-8086ff (oder auch anderer) führt. Die Hardwarefähigkeiten werden hier in keiner Weise vollständig und/oder oft nur durch die Hintertür ausgenutzt. Das sorgt dafür, dass trotz erheblich gewachsener Rechenleistung der PCs hier sehr viel Zeit mit Umwegen verdödelt wird, also keinesfalls die volle Leistungsfähigkeit der Hardware ausgenutzt werden kann.

Ein gutes alternatives Konzept war mMn das Unitkonzpt von Borland Pascal. Dies ermöglichte auch eine volle Wiederverwendung von fertigen Modulen bei gleichzeitig extrem schlanken und schnellem Code des Endproduktes. Eine Unit kam quasi einer Klasse gleich und konnte alle Funktionalitäten anderer Units nutzen oder überschreiben.

Und mit dem DPMI konnte man auch schon sehr früh 16MB Speicher verwalten, was heutzutage sicherlich ein Witz ist, damals aber sehr viel wert war.

Wir hatten hier neulich erst einen Fall, bei dem der Poster fragte, ob die von ihm gefundene Klasse für den Zugriff auf MySQL-Datenbankserver sinnvoll sei. Der Thread ergab sehr schnell, dass der Autor der Klasse OOP missverstanden haben muss...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Peter Nack]

Hallo Tom,

ist das ein Ausschnitt aus dem Buch? Der Text reiht sich ja gnadenlos in den sprachlichen und vor allem inhaltlichen Stil des verlinkten Artikels ein.

Da ich hier allerdings die Moeglichkeit habe etwas naeher nachzuhaken, habe ich mal ein paar Fragen zu deinen Ausfuehrungen. Vielleicht kommt durch die Beantwortung dessen ja zumindest etwas Fachlichkeit ins Spiel.

OOP ist ohne passende Entwicklungsumgebung nicht sehr sinnvoll

_Programmieren_ ist ohne passende Entwicklungsumgebung nicht sehr sinnvoll.

[..] weil es ungeheuer aufwändig ist, die jeweiligen Rahmenbedungungen "zu Fuß" einzustellen und zu überprüfen.

Von welchen "Rahmenbedingungen" sprichst du hier? Was muss wo "eingestellt" und was wo "ueberprueft" werden?

[..] Ist die IDE mächtig, liefert sie auch gleich eine Klassensammlung mit.

Von was fuer sogenannten "Klassensammlungen" sprichst du hier?

Diese schränkt dann die Freiheit des Entwicklers ein.

Eine IDE schraenkt die Freiheit eines Entwicklers ein? Oder beziehst du dich auf dein obiges Missverstaendnis bezgl. der "Klassensammlungen"?

Hinzu kommt hier auch meistens die mMn falsche Vorgabe der freien Portierbarkeit,

Wie kommst du jetzt von OOP auf IDE auf Fraemwork auf Portierbarkeit?

[..] mangelhaften Unterstützung der äußerst gängigen Plattform Intel-8086ff (oder auch anderer) führt.

Wo genau ist die Unterstuetzung mangelhaft?

Die Hardwarefähigkeiten werden hier in keiner Weise vollständig und/oder oft nur durch die Hintertür ausgenutzt.

Um welche Hintertueren handelt es sich hier im Einzelnen?

Das sorgt dafür, dass trotz erheblich gewachsener Rechenleistung der PCs hier sehr viel Zeit mit Umwegen verdödelt wird

Geht es Dir hier immernoch um die "Hintertueren"? Von welche "Umwegen" ist hier die Rede?

Ein gutes alternatives Konzept war mMn das Unitkonzpt von Borland Pascal.

no comment.

[..] bei gleichzeitig extrem schlanken und schnellem Code des Endproduktes. Eine Unit kam quasi einer Klasse gleich und konnte alle Funktionalitäten anderer Units nutzen oder überschreiben.

S.o.

Hier noch einmal eine kurze Zusammenfassung deiner "Kritiken" gegen OOP:

• Es wird eine IDE benoetigt
• die "Rahmenbedingungen" sind aufwaendig
• "Klassensammlungen" werden mitgeliefert
• dies fuehrt zu Einschraenkungen der Freiheit
• OOP gaukelt Vorgaben der Portierbarkeit vor
• Die Hardwarefaehigkeiten werden durch Hintertueren bedient
• Leistungsfaehigkeit wird durch Umwegen beschraenkt

Und nun die finale Frage:
Was hat all das nun mit dem KONZEPT von OOP zu tun?

[Tom]

Hello,

Hier noch einmal eine kurze Zusammenfassung deiner "Kritiken" gegen OOP:

• Es wird eine IDE benoetigt
• die "Rahmenbedingungen" sind aufwaendig
• "Klassensammlungen" werden mitgeliefert
• dies fuehrt zu Einschraenkungen der Freiheit
• OOP gaukelt Vorgaben der Portierbarkeit vor
• Die Hardwarefaehigkeiten werden durch Hintertueren bedient
• Leistungsfaehigkeit wird durch Umwegen beschraenkt

Ich weiß zwar nicht, warum Du mir das Wort im Mund umdrehst, aber überdenke doch nochmal, was Du mir unterstellst. Aber vorher lies nochmal durch, was ich wirklich geschreiben habe.

Und nun die finale Frage:
Was hat all das nun mit dem KONZEPT von OOP zu tun?

Nachdem Du mir meine Aussagen verdreht hast, stellst Du dann diese Frage?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[flowh]

Hallo Tom.

Ehrlicherweise muss ich zugeben, dass ich auch nicht verstanden habe, was eigentlich die Aussage deines Postings war.

Servus,
Flo

[Peter Nack]

Hallo Tom,

aber überdenke doch nochmal, was Du mir unterstellst.

Ich habe bisher doch noch gar nichts unterstellt. Ich habe lediglich ein paar Fragen zu deinen Ausfuehrungen gestellt. Davon lebt ja schlieszlich ein Forum wie dieses. Und gerade wundere ich mich, warum du zumindest nicht einmal versuchst Licht ins Dunkle zu bringen. Und was ist denn das ueberhaupt fuer eine Art, einen Beitrag zu posten und anschlieszend auf Fragen zu eben diesen Beitrag nicht einzugehen?

Aber vorher lies nochmal durch, was ich wirklich geschreiben habe.

Aber genau das habe ich doch getan! Ich habe mir nun sogar die Muehe gemacht, dir deine Ausfuehrungen noch einmal aufzuzeigen.
Also:

Du schriebst:

[..] Entwicklungsumgebung [..], weil es ungeheuer aufwändig ist, die jeweiligen Rahmenbedungungen "zu Fuß" einzustellen und zu überprüfen.

Ich fragte:

Von welchen "Rahmenbedingungen" sprichst du hier?

Du schriebst:

Ist die IDE mächtig, liefert sie auch gleich eine Klassensammlung mit.

Ich fragte:

Von was fuer sogenannten "Klassensammlungen" sprichst du hier?

Du schriebst:

Diese schränkt dann die Freiheit des Entwicklers ein.

Ich fragte:

Wo wird die Freiheit eingeschraenkt?

Du schriebst:

Hinzu kommt hier auch meistens die mMn falsche Vorgabe der freien Portierbarkeit,

Ich fragte:

Wie kommst du jetzt von OOP auf Portierbarkeit?

Du schriebst:

mangelhaften Unterstützung der äußerst gängigen Plattform Intel-8086ff

Ich fragte:

Wo genau ist die Unterstuetzung mangelhaft?

Du schriebst:

Die Hardwarefähigkeiten werden hier in keiner Weise vollständig und/oder oft nur durch die Hintertür ausgenutzt

Ich fragte:

Um welche Hintertueren handelt es sich hier?

Du schriebst:

trotz erheblich gewachsener Rechenleistung der PCs hier sehr viel Zeit mit Umwegen verdödelt wird

Ich fragte:

Von welche Umwegen ist hier die Rede?

Du schriebst:

trotz erheblich gewachsener Rechenleistung der PCs hier sehr viel Zeit mit Umwegen verdödelt wird

Ich fragte:

Von welche Umwegen ist hier die Rede?

Das ist ein klassisches Frage-Antowrt-Spiel. Hierbei besteht doch uberhaupt nicht die Moeglichkeit die "Worte im Mund umzudrehen".
Du gibst eine Aussage von dir, und ich frage dich hierzu etwas. Da ist doch gar kein Platz fuer Spielraum.

Und wenn du deine Aussagen - sicherlich wie der Author des verlinkten Textes auch - nicht begruenden kannst: OK, dann ist dem halt so. Dann frage ich mich jedoch, was so ein Beitrag hier verloren hat bzw. ob dich das persoenlich nicht selbst stoert, eine Meinung zu vertreten, welche du nicht argumentativ begruenden kannst, ferner fuer die nicht einmal logische Zusammenhaenge existieren.

MfG
Peter

[jobo noreg]

Hallo Peter,

mMn. hast du vollkommen Recht.

Gruß,

jobo no reg, da normalerweise hier mein Filter zuschlagen würde ...

[Peter Nack]

Hallo Jobo,

mMn. hast du vollkommen Recht.

Sein nun tagelanges Stillschweigen zeigt, dass er sich dessen wohl nun auch bewusst geworden ist. Auch wenn in diesem Falle eigentlich noch ein abschlieszendes Statement seinerseits angebracht waere  - doch dies von ihm zu erwarten, ist wohl eindeutig zu viel verlangt.

Danke & mfg
Peter

[Christian Seiler]

Hallo Tom,

[...] falsche Vorgabe der freien Portierbarkeit, die im Falle von z.B. C++ zu einer extrem mangelhaften Unterstützung der äußerst gängigen Plattform Intel-8086ff (oder auch anderer) führt. Die Hardwarefähigkeiten werden hier in keiner Weise vollständig und/oder oft nur durch die Hintertür ausgenutzt. Das sorgt dafür, dass trotz erheblich gewachsener Rechenleistung der PCs hier sehr viel Zeit mit Umwegen verdödelt wird, also keinesfalls die volle Leistungsfähigkeit der Hardware ausgenutzt werden kann.

Ich möchte Dich auf das Projekt Eigen aufmerksam machen. Das ist eine C++-Bibliothek für lineare Algebra, d.h. Operationen mit Matrizen und Vektoren. Diese Bibliothek zeichnet sich dadurch aus, dass sie die Möglichkeiten von C++-Template-Metaprogrammierung vollständig ausreizt.

Normale Bibliotheken für lineare Algebra wie BLAS/LAPACK stellen eine ganze Reihe von spezialisierten Funktion bereit, die bestimmte hochspezifische Aufgaben erledigen, die selbst noch einmal durch eine Reihe von hochspezialisierten Parametern beeinflusst werden können. Siehe zum Beispiel die Übersicht über BLAS-Routinen im LUG. Wenn irgend eine spezifische Kombination nun aber nicht implementiert ist in dieser Bibliothek, muss man sich selbst überlegen, wie man das am effizientesten implementiert. Und dann reizt man Prozessorfeatures für Vektorisierung (SSE) usw. eben in der Regel nicht oder nur unzureichend (wenn der Compiler automatisch solchen Code generiert) aus.

Der Ansatz von Eigen ist ein völlig anderer: Anstelle, dass man eine Bibliothek hat, die Routinen enthält, die für alle möglichen Spezialfälle ausgelegt sind, nutzt man C++-Template-Metaprogrammierung. Eigen besteht *ausschließlich* aus C++-Headerdateien. Wenn man diese einbindet und Eigen nutzt, dann wird zur Compilezeit auf Grund der C++-Templates an der Stelle ein hochoptimierter Code *generiert*.

Das heißt: Man verwendet Objektorientierung. Eine Matrix ist eine Klasse. Ein Vektor ist eine Klasse. Operationen sind als überladene Operatoren und Methoden dieser Klassen definiert. Der Sourcecode ist damit extrem leserlich. Wenn man dann allerdings so etwas schreibt wie

vektor2 = matrix * vektor1;

und das dann mit dem Compiler übersetzt, dann wird durch die C++-Templates an der Stelle zur Compilezeit hochoptimierter Assembler-Code erzeugt, der diese Operation mit allen modernen Features des Prozessors durchführt.

Klar, für so etwas simples wie das Matrix-Vektor-Produkt gibt es natürlich auch optimierte Routinen in anderen Bibliotheken. Nur hat man dort das Problem, dass man sich erst mühsam immer wieder die Routinen aussuchen muss, die der effizienteste Weg sind, das Problem zu lösen. Und wenn es für einen Spezialfall gerade keine Routine gibt, dann muss man irgendwie drum herum arbeiten.

Eigen reduziert dieses Problem, in dem der optimierte Code zur Compilezeit generiert wird. Die Template-Logik von Eigen sorgt dafür, das in den allermeisten Fällen Code automatisch generiert wird, der für das *spezifische* Problem optimiert ist, das der Programmierer im Auge hatte. Die Bibliothek richtet sich also nach dem Programmierer. Und dennoch ist Eigen portabel, es nutzt Compiler-Erweiterungen nur in Verbindung mit einem Fallback auf Standard-C++-Features. Die Logik erkennt zur Compilezeit, welche Assembler-Befehle es für den Zielprozessor generieren darf und nutzt im Zweifelsfall die ganz normale FPU.

Daher ist Eigen eine eindrucksvoller Beweis, dass man die Vorteile von Objektorientierung nutzen kann, in dem man eine schöne, gut verständliche Syntax hat für die Operationen (und nicht irgendwelche Spezialisierungen von Routinen mit obskuren Namen aufrufen muss), gleichzeitig auch noch portabel sein kann, andererseits aber die Performancevorteile von modernen Prozessoren vollständig ausschöpfen kann. Und gerade die Template-Metaprogrammierung macht diese Effizienz in Verbindung mit einer guten Wartbarkeit der Software überhaupt erst möglich. Nicht jedes Sprachfeature, das eine zusätzliche Abstraktionsebene einführt, ist automatisch ein Performancekiller.

Viele Grüße,
Christian