Ist OOP das dominierende Programmiermodell in der realen Welt?

Objekte niemals? Kaum jemals

In der VIEWPOINT-Sektion von Communications of The ACM fand ich einen interessanten Artikel mit dem Titel " Objects Never? Well, Hardly Ever ". Es ist eine radikal andere Perspektive als Objekte zuerst oder Objekte spät. Er schlägt "Objekte - nie" oder vielleicht "Objekte - Graduiertenschule" vor.

Der Autor sprach über OOP und stellte eine Frage zur Verwendung von OOP in realen Programmierumgebungen. Er glaubt, dass OOP nicht das vorherrschende Programmiermodell ist. Beispielsweise würden 70% der Programmierungen für eingebettete Systeme durchgeführt, für die OOP nicht wirklich geeignet sei.

Wenn einige Universitätsprofessoren über die Vorteile von OOP sprechen möchten, sprechen sie über die Wiederverwendung von Code. Als weiteres Beispiel behauptet er erneut, dass dies in der realen Welt nicht der Fall ist. Die Wiederverwendung von Code ist schwieriger als an Universitäten behauptet:

Ich behaupte, dass die Verwendung von OOP nicht so verbreitet ist, wie die meisten Menschen glauben, dass es nicht so erfolgreich ist, wie seine Befürworter behaupten, und dass daher sein zentraler Platz im CS-Lehrplan nicht gerechtfertigt ist.

Es ist interessant für mich zu wissen, wie die Leute im Stapelüberlauf darüber denken. Ist OOP aus Sicht der Programmierer das dominierende Programmiermodell?

Wenn ich nur einen Ansatz wählen / lernen / anwenden sollte, ist es OOP oder nicht? Warum?

Im VIEWPOINT-Bereich von Communications of The ACM

Wenn Sie an praktischer Programmierung interessiert sind , ist das Vorgehen von ACM und ähnlichen die letzte Quelle, die Sie lesen möchten. Dies sind oft [pseudo-] wissenschaftliche Veröffentlichungen, die in der realen Welt keine Anwendung finden. Dies sind oft unorthodoxe Meinungen, die für die Öffentlichkeit gemacht wurden, damit der Schriftsteller sich von der Masse abheben und seine eigene Person fördern kann.

Ich behaupte, dass die Verwendung von OOP nicht so verbreitet ist, wie die meisten Menschen glauben, dass es nicht so erfolgreich ist, wie seine Befürworter behaupten, und dass daher sein zentraler Platz im CS-Lehrplan nicht gerechtfertigt ist.

Ich neige dazu, mit Ihrem Standpunkt nicht einverstanden zu sein. OOP ist weit verbreitet und funktioniert gut. An der Zahl haben OOP-basierte Projekte wahrscheinlich die Entwicklungen anderer Strategien übertroffen (sprechen wir über die moderne Zeit, 15 bis 20 Jahre).

Allerdings ist OOP keine Wunderwaffe. Es funktioniert für einige Entwicklungen, nicht für andere. Genau wie bei jedem anderen Ansatz.

Eine Sache, die ich erwähnen muss, ist, dass ein Lehrplan Wissen über verschiedene Ansätze vermitteln sollte. Wenn es OOP-basiert ist, ist es falsch. Wenn es FP-basiert ist, ist es falsch. Es sollte sie alle abdecken oder dieses Thema überhaupt nicht berühren.

PS Warum ist es wichtig, was dominant ist und was nicht? Nehmen Sie einfach das für das jeweilige Projekt Passende und überlassen Sie die Zahlen den "Forschern".

Wenn OOP das einzige Paradigma ist, das Sie kennen, sollten Sie vielleicht mehr lernen. Aber was bedeutet eigentlich OOP? Bedeutet das Java oder C ++? Bedeutet das Smalltalk? Bedeutet dies, dass Slots und Schließungen mit einstellbaren Werten möglich sind? (Hallo, Schema!) Bedeutet es, dass eine Nachricht gesendet wird? (Hallo Erlang!)

Kurz gesagt, es scheint eine uninteressante Frage zu sein. "Ist OO nützlich ?" ist eine bessere Frage. Und so scheint es auch. (Sicher ist es für mich.)

Wo machen alle Entwickler diese "70% der Programmierungen"? Von allen Entwicklern, die ich kenne, arbeiten weniger als 1% an eingebetteten Systemen.

Wir haben also drei Möglichkeiten:

1. Ich bin einzigartig und alle deine Freunde programmieren wirklich eingebettet
2. Es gibt Armeen von Entwicklern, die irgendwo in einem Keller eingesperrt sind und diese 70% erledigen.
3. Diese Statistik ist erfunden und der Artikel ist Bullshit

Wenn ich keine Beweise dafür sehe, dass Option 1 oder 2 tatsächlich zutrifft, gehe ich zu Option 3.

(Übrigens, ich halte moderne mobile Entwicklung nicht für eingebettetes Programmieren, und mobile Entwicklung ist oft OO, nachdem Apple Sie dazu zwingt, * Objective * C für die Entwicklung für das iPhone zu verwenden.)

Ich habe keine Fakten, die ich verfolgen könnte, aber OOP ist nicht das vorherrschende Programmiermodell. Stellen Sie sich vor, Sie haben alle hausinternen Apps von jemandem entwickelt, der an einem Kurs für visuelle Grundlagen teilgenommen oder Makroprogramme in Excel erstellt hat.

Viele Anwendungen führen nur eine zwingende Programmierung durch, bei der die gesamte Logik in einer einzigen Klasse oder Ansicht zusammengefasst ist. Dies ist wahrscheinlich die überwiegende Mehrheit der internen einfachen Anwendungen, die unternehmensweit ausgeführt werden.

Daran ist nichts auszusetzen, es gibt verschiedene Möglichkeiten, das gleiche Problem zu lösen. Einige sind besser geeignet als andere.

Wie Sie bereits betont haben, ist OOP nicht für alle Szenarien geeignet. Es gibt auch andere Modelle.

Ob OOP das dominierende Programmiermodell ist oder nicht, ist irrelevant. Setzen Sie einfach unterschiedliche Modelle für unterschiedliche Fälle ein.

Es gibt keine Silberkugel.

Worüber Moti Ben Ari argumentiert, ist eine akademische Behauptung, die bereits bedeutungslos ist. Er gibt jedoch selbst an, dass er OOP nie als "sinnvoll" empfunden hat, offensichtlich für Tausende von Entwicklern und Software-Ingenieuren und wurde in vielen, vielen Systemen verwendet ...

Aber der eigentliche Punkt meiner Antwort ist: Was nützt es, zu behaupten, dass das eine oder das andere Modell dominant ist oder nicht, ist das dann ein guter Grund, es blind zu benutzen? Natürlich nicht.

Dies ist tatsächlich eine schwierig zu beantwortende Frage. Der Hauptgrund sind Leute wie ich, die in kundenspezifischen Inhouse-Anwendungen arbeiten, bei denen der Code unser Gebäude nie verlässt. Verwenden wir hier OO? Ich sage nicht. Wie viele andere Programmierer haben ähnliche Jobs? Sie sagen es auch nicht. Wir haben zwar Job-Websites, aber nicht alle Jobs sind veröffentlicht, und nicht alle Buchungen sind für echte Jobs bestimmt, im Gegensatz zu Personalbeschaffern, die versuchen, Namenslisten zu sammeln.

Auch wenn ich gesagt habe, wir verwenden OO, wo ich arbeite, bedeutet das die traditionelle Definition aus dem verknüpften Artikel: Objekte, Klassen, Vererbung? Oder bedeutet das, dass ich Objekte hauptsächlich zum Organisieren von Code verwende? Oder heißt das, dass ich wirklich nur auf Schnittstellen programmiere und kaum Vererbung nutze? Ich sage immer noch nicht, aber was von diesen zählt wirklich als OO?

Es ist nicht einmal sinnvoll zu fragen, ob OO nützlich ist, bis die obigen Fragen beantwortet wurden, geschweige denn dominant.

Natürlich, denn es ist das neueste Schlagwort, an das sich das Management gehalten hat. Es bietet auch eine bessere Kapselung und Abstraktion als das imperative Programmieren, daher denke ich, dass der Sprung von OOP zu dem, was als nächstes kommt, noch länger dauern könnte, als es das Imperative dauerte.

PS2: Wenn ich nur einen Ansatz wählen / lernen / anwenden sollte, ist es OOP oder nicht? Warum?

Wenn Sie nur eines lernen möchten, sollten Sie ein anderes Fach auswählen.

Sie sollten sich mit den Typen und der Kapselung sowie allen anderen Vorteilen von OOP vertraut machen und anschließend lernen, wie Sie dieselben Aufgaben mit einem funktionalen Programmierstil ausführen.

OOP ist definitiv eines der dominantesten Programmiermodelle in der realen Welt.

Seien wir ehrlich, sogar Leute, die digitale Hardware entwerfen, die Chip-Designer selbst, machen einen Übergang zum Duo von SystemVerilog und SystemC. Dies sind objektorientierte Programmiersprachen.

Wo würde OOP nicht verwendet werden? Nun, wenn Sie Gerätetreiber codieren, ist es schwer vorstellbar, warum Sie eine generische Programmierung oder Mehrfachvererbung benötigen, ODER wenn Sie AI-funktionale Programmiertechniken anwenden, wird dies für den Kopf viel einfacher. Es gibt auch eine Menge anderer Situationen, obwohl OOP ein ziemlich mächtiger Ort ist, um in einer oligopolistischen Programmierwelt zu sein.

Ich würde nein sagen.

Ich verstehe, dass es eine große Menge Code gibt, der in einer 'objektorientierten' Sprache geschrieben ist, aber im Allgemeinen stelle ich fest, dass der Code nur prozedural in Klassen verpackt ist. (nicht, dass dies unbedingt eine schlechte Sache ist). Der Code, den ich gesehen habe und der in diesen Sprachen für mehr OO geschrieben wurde, ist in der Regel ein schreckliches Durcheinander von Abhängigkeiten zwischen Klassen, das normalerweise nicht gewartet werden kann.

Bei OO soll es sich um die Weitergabe von Nachrichten zwischen vollständig in sich geschlossenen Objekten handeln, und das sehen wir im heutigen Code, aber auf einer viel detaillierteren Ebene - dh wir sehen diese Objekte als DLLs, Assemblys oder COM-Objekte implementiert. "Komponenten", wie ich sie beschrieben habe.

Daher denke ich, dass es eigentlich egal ist, ob OO verwendet wird oder nicht - wenn der Code während seiner Lebensdauer gewartet werden kann, in dem Maße wiederverwendbar ist, wie er entworfen wurde und sich schnell entwickelt, ist es mir egal wenn es rein prozedural oder semi-objektorientiert oder vollständig OO ist. Ich bezweifle, dass Ihnen jemand sagen kann, ob der vorherrschende Stil einer dieser Stile ist, aber ich würde eine Vermutung anstellen, dass der prozedurale Stil der häufigste sein wird, auch wenn er in Klassen anstatt in Funktionen zerlegt wird.

Ich denke, dass es wichtig ist, eine Lösung zu differenzieren, die durch Anwendung eines objektorientierten Ansatzes und einer Lösung, die unter Verwendung des objektorientierten Paradigmas implementiert wurde, erhalten wird. Meine Meinung zu einer guten objektorientierten Software ist, beide Lösungen zu kombinieren. Wenn Sie in Objekten denken und die Objektdefinitionen und Interaktionen respektieren und Ihr Problem an die Verwendung dieser Struktur angepasst werden könnte, verfügen Sie über einen Code, der flexibel und robust ist. Wenn Sie jedoch Objekte verwenden, um einen Code mithilfe eines prozeduralen Paradigmas zu lösen, werden Sie eine böse Mischung erhalten, die die Vorteile von Objects nicht ausnutzen wird.

Ich bevorzuge wirklich, dass mein Code objektorientiert ist, und mir ist klar geworden, dass es anfangs etwas ärgerlicher sein könnte, eine gute Struktur zu erstellen, aber wenn ich mich mit der Flexibilität und den Flash-Anforderungen von Kunden von heute befasse, denke ich, dass es das wert ist Anstrengung.

Ich gebe nicht vor, die genauen Zahlen zu kennen oder auch nur eine grobe Vermutung anzustellen, aber es gibt viele Programmierprojekte, die keine OOP beinhalten. Ich arbeite mit Industrierobotern. Die Programme sind in der Regel recht einfach und unkompliziert. Das tatsächliche Betriebssystem des Roboters ist noch mehr.

Viele unserer "Tools" basieren auf OOP, laufen jedoch auf PCs und nicht auf der Robotersteuerung. Dazu gehören Editoren, Simulationen und Dienstprogramme.