Oo Diskussion
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Veränderung (letzte Änderung) (Korrektur, Autor, Normalansicht)

Verändert: 68c68
:: Ich werde es versuchen: WasIstKomplexität. Die Erhöhung der Komplexität ist für mich zunächst ein empirischer Befund, der sich auf Systeme wie Smalltalk, C++, CommonLisp oder Java (im Gegensatz zu Fortran, C, Pascal oder Perl) gründet. Die Komplexität äußert sich u.a. in der versteckten inneren Komplexität der Implementierung, im Sprachumfang, im Umfang der APIs und auch in der Größe der Runtime-Umgebung bzw. der typischen Entwicklungsumgebungen. Ein 32-KB-Apple-II konnte eine UCSD-Pascal Applikationsentwicklung tragen. Heute kann ein 32-MB-PDA kaum eine Java-Entwicklungsumgebung tragen.
:: Ich werde es versuchen: WasIstKomplexität. Die Erhöhung der Komplexität ist für mich zunächst ein empirischer Befund, der sich auf Systeme wie Smalltalk, C++, CommonLisp oder Java (im Gegensatz zu Fortran, C, Pascal oder Perl) gründet. Die Komplexität äußert sich u. a. in der versteckten inneren Komplexität der Implementierung, im Sprachumfang, im Umfang der APIs und auch in der Größe der Runtime-Umgebung bzw. der typischen Entwicklungsumgebungen. Ein 32-KB-Apple-II konnte eine UCSD-Pascal Applikationsentwicklung tragen. Heute kann ein 32-MB-PDA kaum eine Java-Entwicklungsumgebung tragen.

Verändert: 120c120
:: ... oder, dass die meisten Leute nicht wissen wovon sie reden. Ich fasse es immer noch nicht, daß es in der Java API eine Klasse FilePermissions? gibt, daß als Parameter "read", "write" oder "read,write" akzeptiert.
:: ... oder, dass die meisten Leute nicht wissen wovon sie reden. Es ist unglaublich, daß es in der Java API eine Klasse FilePermissions? gibt, deren Konstruktor als Parameter "read", "write" oder "read,write" akzeptiert, anstatt eines Objektes, wie es das EnumerationDesignPattern? zeigt. (Bzgl. OO wäre ein Objekt einer Enumeration eben besser, da eindeutiger und weniger fehleranfällig).

Verändert: 122,126c122
:::Warum nicht - und wofür oder wogegen genau ist das ein Argument???

:::: Ich denke mal, er meinte den Konstruktor (nicht die Klasse), und daß dort als Parameter ein String statt eines Objektes, wie es das EnumerationDesignPattern? zeigt, eingesetzt wird und bzgl. OO ein Objekt einer Enumeration eben besser wäre, da eindeutiger und weniger fehleranfällig.

::: Man muss halt sehen, dass die Programmierer bei Sun tatsächlich noch dabei sind, ObjektOrientierteProgrammierung zu lernen! Immerhin sollen im JDK1.5 TypesafeEnums? direkt in die Sprache aufgenommen werden...
::: Man muss halt sehen, dass die Programmierer bei Sun tatsächlich noch dabei sind, ObjektOrientierteProgrammierung zu lernen! Immerhin sollen im JDK1.5 TypesafeEnums? direkt in die Sprache aufgenommen werden... [und sowas trauen sie sich zu verkaufen ...]

Es ist erstaunlich, dass nach so vielen Jahren OO die Diskussionen über dieses Paradigma immer noch nicht abgeschlossen sind:

Vermutlich hängt das damit zusammen, dass OO zwar einerseits unbestreitbare Vorteile hat. Andererseits sind aber auch Nachteile vorhanden und diese scheinen für manche Entwickler oder in manchen Situationen derart zu überwiegen, dass eine permanente Frontlinie zwischen Befürwortern und Gegnern entstanden ist. Diese Frontstellungen lassen sich aus den Diskussionen über technische Details allein nicht verstehen.

Es geht dabei weniger um technische Details als um gegensätzliche zugrundeliegende Weltsichten.

Faktoren pro OO

Das OO Paradigma hat für die Hersteller von Programmiersprachen und Tools neue Entwicklungsschienen und neue Einnahmequellen geöffnet. Aus neuen Versionen der standardisierten Sprachen hätten sich zu geringe Umsätze ergeben. Neue prozedurale Sprachen hätten vermutlich nicht genügend Vorteile bieten können, um sich gegen etablierte Sprachen durchzusetzen.

Andererseits ist Stagnation nicht die einzige Alternative - die Hersteller hätten sich auch einfach auf andere Paradigmen wie die FunktionaleProgrammierung stürzen können.

Das OO Paradigma ist vor allem theoretisch und methodisch attraktiv. Damit harmoniert es bestens mit den Universitäten. Sie produzieren massenweise Absolventen, die zwar nicht gut Software entwickeln können, aber von den Vorzügen von OO überzeugt sind. Viele Sprachen (Pascal, Modula, Eiffel, ...) sind universitär entstanden und teilweise favorisiert worden, ohne dass sie sich in der Praxis bewährt hätten.

Gute OO Entwicklung ist durchaus auch in der Praxis sehr attraktiv - Du hast aber vermutlich recht, dass diese nur selten in der Uni gelehrt wird.

Inwiefern ist gerade das OO Paradigma attraktiv, speziell im Vergleich zur funktionalen Programmierung?

Persönlich finde ich die FunktionaleProgrammierung durchaus interessant - um sie attraktiv zu finden, habe ich noch nicht genügend Erfahrung darin.

Allgemein denke ich, FunktionaleProgrammierung hat Probleme sich durchzusetzen, weil der Sprung von der prozeduralen Programmierung, mit der die meisten Programmierer ihre ersten Erfahrungen sammeln, zur funktionalen einfach größer ist als zur objektorientierten...

Das OO Paradigma bringt seine Vorteile vor allem in der industriellen Software-Produktion, dort wo man sich von einzelnen Entwicklern und von der Qualität der Entwickler unabhängig machen möchte. Es ist aber noch offen, ob sich das Bild einer Massenfertigung auf die Softwareentwicklung sinnvoll übertragen lässt.

Das Bild lässt sich sicherlich nicht übertragen. Das OO vor allem "in der industriellen Software-Produktion" (was immer das ist) Vorteile bringen soll, kann ich aber auch nicht nachvollziehen (siehe unten).


Ein Haupt-Vorteil von OO Entwicklung ist in meinen Augen, dass sie auf einem intuitiv recht naheliegenden und weniger willkürlichen Modularisierungsbegriff aufbaut, indem sie Algorithmen, die auf gleichartigen Datenstrukturen operieren, zu einer Klasse zusammenfasst.

Ein zweiter Vorteil ist, dass sie via Vererbung und Polymorphismus ermöglicht, Problemlösungen, die mit Klassen beschrieben werden, einerseits teilweise zu übernehmen, aber andererseits zugleich zu variieren und zu spezialisieren, ohne dass man gleich alles neu machen muss.

Der herkömmlichen OOP fehlen jedoch noch einige weitere wünschenswerte Strukturierungsmöglichkeiten "im Großen" wie auch "im Kleinen":

"Im Großen" möchte man Familien kooperierender Klassen (mit Parameter-Klassen) bilden können und damit komplexere Problemlösungen beschreiben, die sich wiederum spezialisieren/variieren lassen (durch gleichzeitige Spezialisierung der Parameter-Klassen). Der "Package"-Begriff in SpracheLava ist ein Ansatz, der diese Lücke zu schließen versucht.

Weiterhin hätte man gerne "im ganz Großen" ein einheitliches Konzept von OOP und "autonomen Software-Komponenten", deren Schnittstelle(n) sich zur Programmierzeit in die benutzte Programmiersprache "importieren" und die sich zur Laufzeit dynamisch an eine Anwendung "andocken" lassen. Typischerweise haben die Komponenten persistentes Gedächtnis, seien es die dauerhaft veränderbaren Einstellungen/Properties von ActiveX? Controls, COM-Komponenten oder Java Beans, oder das umfangreichere Gedächtnis von Dateien, Datenbanken, Web-Seiten, Mail-Boxen, FTP-Verzeichnissen, usw.. Auch zu einer solchen vereinheitlichten Sicht von Komponenten enthält SpracheLava erste Ansätze.

"Im Kleinen" möchte man beim Spezialisieren von Klassen oder auch beim Entwickeln von Methoden für ein und dieselbe Klasse nicht immer ganze Methoden komplett durch "Überschreibungen" ersetzen, sondern im Rumpf einer Methode spezialisierenden Code an einer oder mehreren Stellen einsetzen können, ohne den Basis-Code erst zu kopieren/vervielfältigen und damit den spezialisierten vom Basis-Code abzulösen und unabhängig zu machen.

Manche Bedürfnisse dieser Art versucht man z.B. in C++ mit Makros zu befriedigen, etwa wenn viele Methoden einer Klasse in ihrem Rumpf am Anfang und Ende eine immer gleiche Anfangs- und/oder Ende-Behandlung haben sollen. Statt Makros hätte man hier gerne einen der oo Denkweise besser angemessenen Begriff von inkrementeller Code-Spezialisierung. Ich denke, dass sich dies in einer auf Struktureditoren (statt Texteditoren) aufbauenden Programmiertechnik ganz natürlich lösen ließe, und wir spielen mit dem Gedanken, dies in einer künftigen Version von SpracheLava auch zu versuchen. --kg

Für diesen letzten Punkt wird gerade die sogenannte AspektOrientierteProgrammierung entwickelt. Dabei wird versucht gewisse Aspekte - wie zum Beispiel Synchronisierung - zu Extrahieren und als Rezept den Klassen bei der Kompilation hinzuzufügen.

Die AOP (am besten vielleicht durch die Java-Variante AspectJ bekannt) hat, wie alle Verfahren der GenerativeProgrammierung, den Nachteil, dass Programme textuell aus unvollständigen, für sich nicht sinnvollen und verständlichen Code-Schnipseln zusammengesetzt werden. Demgegenüber verspreche ich mir von einer Unterstützung mit Struktureditoren, dass der Programmierer immer vollständige, für sich verstehbare Programmbausteine sieht, obwohl die zusammengefügten Inkremente intern sicher separat gespeichert werden. --kg


MiguelDeIcaza über Entwicklung mit mono (der OpenSource .NETFramework Implementierung; MonoProject):

Evolution took us two years to develop and at its peak had 17 engineers working on the project. I want to be able to deliver four times as many free software applications with the same resources, and I believe that this is achievable with [mono/the .net framework].

An einer anderen Stelle des Artikels:

There is a point in your life when you realize that you have written enough destructors, and have spent enough time tracking down a memory leak, and you have spend enough time tracking down memory corruption, and you have spent enough time using low-level insecure functions, and you have implemented way too many linked lists

Faktoren contra OO

Das OO Paradigma bringt ziemlich komplexe Gesamtsysteme mit sich. Komplexität bedeutet immer auch höhere Kosten.

Bitte definiere hier "Komplexität" und erkläre, wie OO diese erhöht.

Ich werde es versuchen: WasIstKomplexität. Die Erhöhung der Komplexität ist für mich zunächst ein empirischer Befund, der sich auf Systeme wie Smalltalk, C++, CommonLisp oder Java (im Gegensatz zu Fortran, C, Pascal oder Perl) gründet. Die Komplexität äußert sich u. a. in der versteckten inneren Komplexität der Implementierung, im Sprachumfang, im Umfang der APIs und auch in der Größe der Runtime-Umgebung bzw. der typischen Entwicklungsumgebungen. Ein 32-KB-Apple-II konnte eine UCSD-Pascal Applikationsentwicklung tragen. Heute kann ein 32-MB-PDA kaum eine Java-Entwicklungsumgebung tragen.

Die größten Kosten verursachen aber im Allgemeinen Entwicklung und Wartung - wenn man es also schafft, Entwicklungskosten durch Einsatz von komplexeren Laufzeitsystemen etc. zu verringern, könnte es sein, dass dadurch die Gesamtkosten verringert werden.

Außerdem ist zu beachten, dass sich auch die Anforderungen an die Systeme nicht unwesentlich erhöht haben.

Es ist schwieriger, große OO Klassenhierarchien zu überblicken und effizient zu nutzen, als prozedurale Bibliotheken.

Warum? Auf Grund der Komplexität.

Du hast noch nicht erklärt, inwieweit (und warum) OO APIs inherent komplexer sind als prozedurale mit vergleichbarem Funktionsumfang...

OO Systeme benötigen beim Entwickler und beim Anwender mehr CPU-Leistung und mehr Speicher-Ressourcen [als prozedurale Sprachen].

Mehr als was für Systeme? Warum? w. o.

Dito... ;)

Sie bedingen mehr anfänglichen Lernaufwand

Inwiefern? w. o.

Einige Vorteile der OO kommen erst bei grösserem Umfang zum Vorschein.

und durch ihre geringere Stabilität auch einen größeren laufenden Lernaufwand.

Was für geringere Stabilität? Langzeit-Stabilität der APIs. Z. B. laufen meine im Jahr 2001 - mit der mir damals möglichen Sorgfalt - geschriebenen Java-Applets und -Applikationen (1.2) laufen nicht zuverlässig auf verschiedenen Runtimes und Browsern.

Das würde ich aber eher auf die miese Qualität der Implementierung durch Sun (und die Browserhersteller) zurückführen.

Ganz generell läßt sich in den Kommentaren hier eine unterschwellige Gleichsetzung von OO und Java herauslesen.

Mich würde auch interessieren, inwiefern eine prozedurale API hier günstiger gewesen wäre...

Das OO Paradigma bringt für hochqualifizierten Einzelkämpfer (Dinosaurier) kaum Vorteile. Es werden keinen neuen Anwendungsfelder zugänglich gemacht, sondern die vorhandenen Funktionalitäten werden anders verpackt. Verpackung ist aber auch Overhead. Der Beweis, dass sich große prozedurale Systeme (UNIX, TEX) mit Vorteilen in eine OO Welt transformieren lassen, ist bis heute nicht gelungen. Der Einzelkämpfer bewertet auch die Langzeit-Stabilität der Systeme, die effiziente Ressourcen-Nutzung, die Abhängigkeiten von Runtime-Environments und die Abhängigkeit von Herstellern anders als die öffentliche Mehrheit.

Genau die gleichen Argumente ließen sich auch für Assembler kontra prozeduraler Programmerierung bringen. Nein, die Betriebssysteme haben sich aus der Assembler-Welt in die prozedurale Welt bewegt. Das gleiche gilt für alle wesentlichen früheren Assembler-Applikationen.

Und Du gehst davon aus, dass das mit OO nicht passieren wird?

Nach meiner Erfahrung bringt OOP sehr wohl große Vorteile auch für "Einzelkämpfer" - als Tool, um Abhängigkeiten im Quellcode zu managen. -- IljaPreuß

anders verpackt Dies bedeutet doch, es gibt auch ohne OO eine Verpackung. Worin liegt denn der grössere Overhead bei OO?


...lässt sich Gleichsetzung von OO und Java herauslesen...

Na ja, ich habe mich in zwei kritischen Anmerkungen auf Java bezogen. Java war auch - über die letzten 10 Jahre gerechnet - der Inbegriff der modernen OO Sprache.

Was ein ziemlich deutliches Zeichen dafür ist, dass OOP sich noch nicht wirklich durchgesetzt hat... ;^)

... oder, dass die meisten Leute nicht wissen wovon sie reden. Es ist unglaublich, daß es in der Java API eine Klasse FilePermissions? gibt, deren Konstruktor als Parameter "read", "write" oder "read,write" akzeptiert, anstatt eines Objektes, wie es das EnumerationDesignPattern? zeigt. (Bzgl. OO wäre ein Objekt einer Enumeration eben besser, da eindeutiger und weniger fehleranfällig).

Man muss halt sehen, dass die Programmierer bei Sun tatsächlich noch dabei sind, ObjektOrientierteProgrammierung zu lernen! Immerhin sollen im JDK1.5 TypesafeEnums? direkt in die Sprache aufgenommen werden... [und sowas trauen sie sich zu verkaufen ...]

Meine Anmerkungen in Bezug auf Java sind aber eher Zufall, weil ich mit Java einiges gemacht habe und in Summe dann doch eher enttäuscht war. Es ist aber die Frage, welche andere Sprache prototypisch für OO stehen könnte (C++ ist doch sehr hybrid, Smalltalk und Eiffel zu weit vom Mainstream, Ruby und Python eher im Scriptbereich als für die Applikationsentwicklung, C# ist MS und zu neu, ...)? -- HelmutLeitner

Wäre es bei der Betrachtung der Sinnhaftigkeit von OOP nicht angebracht, eine gute OO-Sprache unabhängig von ihrer Verbreitung zu bewerten? In diesem Sinne fände ich Smalltalk (z.B.) durchaus einleuchtender als Java...

...inwiefern eine prozedurale API hier günstiger...

Ich beobachte einfach, dass in prozeduralen Sprachen die APIs von Version zu Version nicht so stark verändert wurden. Wenn, dann kommen eher Funktionen dazu, so dass die Systeme aufwärtskompatibel sind.

Hat das nicht eher was mit der Reife der API zu tun? Die ersten Java-Versionen waren unter extremem Zeitdruck entstanden, soweit ich weiß - dass da jetzt auch an existierendem nachgebessert werden muss, überrascht mich da nicht sehr...

Ich schätze auch statisch gelinkte Programme, wo eine Erweiterung der Bibliothek keine Vergrößerung des FootPrint? zur Folge haben muss. Aber ich bin mir bewusst, da eine Minderheitsmeinung zu vertreten. -- hl

Und hoffentlich auch, dass das vollkommen orthogonal zu OOP ist...

Theoretisch ja, aber mir begegnet das nicht in der Praxis. Welche OO Sprache eignet sich für die Applikationsentwicklung und schafft eine kleine GUI-Applikation (inkl. Runtime-Environment oder dyn. Libraries) in 1 MB unterzubringen und läuft in 1 MB RAM? -- hl

Geht das mit C++ nicht? Zumindest weiß ich, dass RobertCMartin bereits von der Entwicklung von EmbeddedSystems? in C++ mit sehr engen Speicherbegrenzungen berichtet hat.

Ja, wenn man keine C++ Libraries und Features verwendet, bleiben die Programme klein wie C-Programme. C++ sehe ich aber als Hybrid (ist mal lang hier diskutiert worden) und nicht als typisch für OO.

Er spricht durchaus von objektorientierter Entwicklung: http://groups.google.com/groups?selm=RMARTIN.96Apr11113222@rcm.oma.com&oe=UTF-8&output=gplain

Letztendlich waren frühe C++ "Compiler" ja nichts anderes als Preprozessoren, die C++ Quellcode in die SpracheCee übersetzt haben. -- IljaPreuß

Das ist aber schon lange her. Für den aktuellen Standard gibt es meines Wissens keine Preprozessor-Lösungen mehr.


KategorieOop
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 14. Januar 2004 21:16 (diff))
Suchbegriff: gesucht wird
im Titel
im Text