Oo In Prozeduralen Sprachen
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

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

Verändert: 51c51
:B erbt von A, so wäre das sinnvoll. Ich habe aber tatsächlich wiederstrebend aus A und B eine gemeinsame Datenstruktur gemacht (für eine einheitliche Schnittstelle). Allerdings habe ich dafür viele case Konstrukte in den dazugehörigen Methoden und eben da auch doppelten Code. Mit OO währe das nicht passiert ... -- mj
:B erbt von A, so wäre das sinnvoll. Ich habe aber tatsächlich widerstrebend aus A und B eine gemeinsame Datenstruktur gemacht (für eine einheitliche Schnittstelle). Allerdings habe ich dafür viele case Konstrukte in den dazugehörigen Methoden und eben da auch doppelten Code. Mit OO wäre das nicht passiert ... -- mj

RobertCMartin am 09.05.2002 in news:comp.object, Betreff "Essential Characteristics of OOP":

>I emphasize, "A good OO design may be implemented 
>with a procedural language".

I disagree.  I think this notion makes some people feel comfortable
that they can be doing OO in their favorite language; but beyond that
I think it's nonsense.

It's not nonsense because it's impossible.  Indeed, it is very
possible to implement an object oriented design in a procedural
language like C.  It's nonsense because implementing an OO application
in a procedural langauge is *hard*.  So hard as to be impractical.  

The difficulty is simply this.  A real OO application requires a
significant amount decoupling through the use of polymorphic
interfaces.  Polymorphic interfaces are implemented in procedural
languages like C through the use of pointers to functions.
Maintaining all these pointers to functions, making sure they are
initialized correctly, and making sure every function invocation is
through a pointer, is very hard.


Und es gibt es trotzdem. Siehe Gtk und der Linux Kernel. Zwei große Projekte in C die beide einiges an OO-Design enthalten.

    Hm, wobei dieses vtable[]-Gegurke nicht das Gelbe vom Ei ist.


Von http://www.luca.demon.co.uk/TheoryOfObjects/Prologue.html (letzter Absatz):

We show that this [programming in object-oriented style within a typed procedural language] is possible in principle, given a sufficiently expressive procedural language, but we argue that this would be too inconvenient in practice. Therefore we find that the expressiveness of object-oriented languages cannot be emulated easily by procedural languages.


Auf die Gefahr mich (in meiner Minderheitsmeinung) zu wiederholen: In weiten Bereichen der Softwareentwicklung kann man objektorientiert programmieren ohne Vererbung, Polymorphismus oder Kapselung (als Hauptmerkmale der OOP) zu benötigen. OoInProzeduralenSprachen bedeutet IMO nicht die Nachbildung von OO Features, sondern eine systemanalytisch klare, an Objekten orientierte Sicht und Modellierung der Wirklichkeit. Dies wird jedoch durch Einsatz von OO Technologie nicht garantiert. Der Gegensatz zwischen prozedural und OO ist IMHO künstlich hochgespielt. Ein Vorteil von prozeduralen Systemen ist ihre geringere Komplexität. Die Reduktion der Komplexität ist aber der Knackpunkt bei den meisten Problemlösungen und Applikationen. -- HelmutLeitner

Mhh, unsere Erfahrung muss sehr unterschiedlich sein. Nach meiner Erfahrung ist Entkopplung ein sehr wichtiger Schritt zur Reduzierung von Komplexität in nicht-trivialen Systemen - und Polymorphie ein sehr mächtiges Werkzeug zur Entkopplung. -- IljaPreuß

Ich sitze gerade an einem solchen Projekt (Ein Pascal Monolith soll refactored werden) ... und kann Ilja nur zustimmen. Ich vermisse Polymorphie wie noch nie im Leben. Ich muss Code duplizieren! Und natürlich ist Entkoppung das wichtigste ab einer bestimmten Projektgröße. -- mj

Schlechten Code gibt es überall und Features, die man gewohnt ist gehen einem in anderen Sprachen ab (seitdem ich "perle" vermisse ich überall die leichten Hashes und Regexps). Könntest du ein Beispiel geben, warum bzw. in welcher Situation du Code duplizieren musst? -- hl

Ich hab eine Archivschnittstelle, die zwei verschiedene Typen A und B archiviren muss. B ist Spezialfall von A, jetzt brauch ich archiv(A) und archiv(B) ohne dass sich die beiden Methoden funktional wesentlich unterscheiden (Ich hab mich dabei aus Komplexitätsgründen bewusst gegen die FunktionsPointerei? entschieden).
Zum zweiten entwickeln ca. 15 Personen mit dem Modul, das ich zur Zeit kapsele. Ich hätte gerne eine Kapselung meiner Datenstruktur, die über gegenseitigen Goodwill hinaus wirksam ist. Ich kann zwar sehr viele Module für alles mögliche machen. Durch fehlendes OO bin ich aber in der Granularität der Modularisierung sehr eingeschränkt. -- mj

Da ich die Situation nicht kenne, hänge ich natürlich mit meinen Annahmen in der Luft. Aber ich spekuliere mal, dassen A und B eigentlich ein Objekt sind und irgendjemand hat einmal (im typischen ÄnderungsPatchwork?, das übrigens auch durch die OO-Vererbungsmechanismen gefördert wird) geflickt und dupliziert statt sich um eine gemeinsame Abstraktion zu bemühen. Bin ich weit von der Wahrheit entfernt? -- hl

B erbt von A, so wäre das sinnvoll. Ich habe aber tatsächlich widerstrebend aus A und B eine gemeinsame Datenstruktur gemacht (für eine einheitliche Schnittstelle). Allerdings habe ich dafür viele case Konstrukte in den dazugehörigen Methoden und eben da auch doppelten Code. Mit OO wäre das nicht passiert ... -- mj

im typischen ÄnderungsPatchwork?, das übrigens auch durch die OO-Vererbungsmechanismen gefördert wird

Inwiefern?


KategorieOop
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 11. September 2002 22:30 (diff))
Suchbegriff: gesucht wird
im Titel
im Text