news:comp.object

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

http://www.luca.demon.co.uk/TheoryOfObjects/Prologue.html

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

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

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

Inwiefern?