Unterstützen Nicht-OOP-Paradigmen Konzepte wie die Kapselung?

12

Eines der wichtigsten Konzepte in der objektorientierten Programmierung ist die Kapselung. In letzter Zeit scheint sich die Software-Welt jedoch zugunsten anderer Paradigmen wie der funktionalen Programmierung zu neigen.

Ich denke, was ist mit Kapselung und anderen OOP-Grundsätzen? Sind sie falsch?

Wird OOP falsch angewendet? Zum Beispiel wird Alan Kay in der OOPSLA'97-Keynote erwähnt: "Ich habe den Begriff objektorientiert erfunden, und ich kann Ihnen sagen, dass ich nicht an C ++ gedacht habe."

Joe Armstrong - "Objekte binden Funktionen und Datenstrukturen in unteilbaren Einheiten zusammen. Ich denke, dies ist ein grundlegender Fehler, da Funktionen und Datenstrukturen in völlig unterschiedliche Welten gehören."

JeffV
quelle
2
Ich würde sagen, die Frage muss zuerst klären, was unter Kapselung zu verstehen ist und was es für die Sprache bedeutet, sie zu unterstützen.
Euphoric
14
Ich habe Probleme herauszufinden, was diese Frage stellt. Wird gefragt, ob die Kapselung außerhalb von OO (Betreffzeile) existieren kann? Wird gefragt, ob die Kapselung falsch ist (zweiter Absatz)? Wird gefragt, ob OO falsch angewendet wird (dritter Absatz)? Und was will das OP mit diesem Zitat von Joe Armstrong sagen? Wie definiert das OP "Kapselung"? Wie definiert das OP "OO"? Was sind diese "anderen Grundsätze"?
Jörg W Mittag
1
Robert Martin hat einmal gesagt, dass OOP die Kapselung weggenommen und sie dann mit schrecklichen Hacks wieder gepatcht hat. "Wir hatten vor oo eine perfekte Verkapselung". Natürlich war er hyperbolisch, aber jetzt erinnere ich mich jedes Mal, wenn ich jemanden sagen sehe, dass es bei OO um Kapselung geht, an Onkel Bob.
GnP

Antworten:

15

Ich denke, die Falle, in die Sie hier geraten sind, besteht darin, dass es eine starre Definition jedes Programmierparadigmas gibt (strukturiert, objektorientiert, funktional usw.).

Wenn Sie zwei verschiedene Entwickler fragen, was OOP bedeutet, erhalten Sie zwei verschiedene Antworten. Ja, als Beruf sind wir uns einig, dass es einige gemeinsame Themen wie Kapselung, Verstecken von Daten usw. gibt, die von einem OOP-Kurs für Softwareentwicklung im College behandelt werden.

In der realen Welt sind die Dinge jedoch nicht ganz so trocken und trocken, weshalb zwei Entwickler zwei unterschiedliche Antworten geben. Vielleicht sind sie Experten in verschiedenen Sprachen, die OOP-Konzepte unterschiedlich ausdrücken. Sprachparadigmen überschneiden sich tendenziell. Die neueste Wut ab 2013 ist die Integration funktionaler Programmierung in objektorientierte Sprachen durch Verschlüsse oder Lambdas. Ist Java 8 objektorientiert oder funktional? Ich würde es objektorientiert mit einem Schuss Funktion nennen. Jemand anderes könnte es anders beschreiben.

Wird OOP falsch angewendet?

Nein, das Problem ist, dass verschiedene Sprachen Programmierkonzepte unterschiedlich ausdrücken. Vielleicht lässt eine Sprache ein OOP-Konzept aus, und eine andere Sprache enthält es, lässt aber ein anderes OOP-Konzept aus. Sprachen sind in der Regel für einen Zweck konzipiert: eine bestimmte Art von Aufgabe zu vereinfachen, auf Kosten anderer Aufgaben. Das ist weder richtig noch falsch, es ist einfach ein realer Kompromiss, der nicht zu vermeiden ist.

Die reale Welt ist nicht das Klassenzimmer. Wir müssen entweder konzeptionelle Programmierparadigmen auf abstrakter Ebene diskutieren oder wir müssen echte Programmiersprachen diskutieren, die gezwungen sind, Kompromisse einzugehen, um nützlich zu sein. Solange eine Programmiersprache hauptsächlich durch eine abstrakte Definition von OOP definiert ist, können wir sie in diesen Bucket aufnehmen.


quelle
10

In letzter Zeit scheint sich die Software-Welt jedoch zugunsten anderer Paradigmen wie der funktionalen Programmierung zu neigen.

Das ist umstritten. Erstens sehe ich außer OOP und funktionaler Programmierung keine anderen Paradigmen, die so ausführlich diskutiert werden. Ich denke, wir können den Satz "andere Paradigmen wie" vergessen. Lassen Sie uns über FP sprechen, sonst nichts.

Die Gründe, warum funktionale Programmierung in den letzten Jahren so populär wurde, wurden in anderen Fragen hier ausführlich diskutiert. Ich werde dies nicht wiederholen (siehe hier oder hier zum Beispiel). Meiner Meinung nach liegt dies jedoch nicht daran, dass "OOP ein großer Fehler war" oder "Functional vs. OOP schließen sich gegenseitig aus", sondern eher daran, dass Leute ihre Toolbox erweitern und versuchen, das Beste aus beiden Welten herauszuholen. Ok, es gibt sicherlich Experten, die Hardliner sind, die einander vorziehen, aber Sie werden diese Leute auf beiden Seiten finden.

Ich denke, was ist mit Kapselung und anderen OOP-Grundsätzen? Sind sie falsch?

Verkapselung hat viele verschiedene Geschmacksrichtungen. Funktionale Programmiersprachen und Sprachkonstrukte bieten bestimmte Formen der Kapselung, andere objektorientierte. Wenn Sie nach Beispielen für die Kapselung mit funktionalen Mitteln suchen, beginnen Sie mit Verschlüssen .

In Bezug auf "andere Grundsätze": Nein, sie sind nicht falsch, aber für bestimmte Szenarien wie die Parallelisierung in großem Maßstab lassen sich funktionale Ansätze wahrscheinlich besser skalieren. Für andere Szenarien, wie das Erstellen gut gestalteter UI-Frameworks, lassen sich OOP-Ansätze wahrscheinlich besser skalieren (YMMV, ich habe nicht nur ein besseres Beispiel zur Hand). Darüber hinaus bin ich mir sicher, dass es für die meisten realen Szenarien vom Wissen und der Erfahrung des Teams mit seinem bevorzugten Programmierparadigma abhängt, wie gut ein bestimmtes System skaliert.

Wird OOP falsch angewendet? Zum Beispiel wird Alan Kay in der OOPSLA'97-Keynote erwähnt: "Ich habe den Begriff objektorientiert erfunden, und ich kann Ihnen sagen, dass ich nicht an C ++ gedacht habe."

Sicherlich wird OOP von vielen Menschen oft falsch angewendet, aber ich bin sicher, dass dies auch für FP gilt. Und ich würde mich wundern, wenn John Mc Carthy (Designer von Lisp) so etwas wie Javascript im Sinn hätte, wenn er über funktionale Programmierung nachdachte (Gnade für mich, flamme mich nicht zu sehr für diesen Vergleich ;-)

Joe Armstrong - "Objekte binden Funktionen und Datenstrukturen in unteilbaren Einheiten zusammen. Ich denke, dies ist ein grundlegender Fehler, da Funktionen und Datenstrukturen in völlig unterschiedliche Welten gehören."

Ich denke, der Erfinder von Erlang hat einige gute Argumente, aber er hat auch seinen eigenen Standpunkt. Lassen Sie ihn also seine Meinung sagen und bauen Sie Ihre eigene auf. Es gibt viele andere Experten, die eine andere Vorstellung davon haben.

Doc Brown
quelle
1
Ich bin mir nicht sicher, ob OO für GUI besonders besser ist, mehr als dass OO und GUIs ungefähr zur gleichen Zeit entstanden sind. +1 für McCarthy / Javascript;)
jk.
1
Um fair zu sein, schlagen einige Leute vor, dass die bestehenden Ansätze fehlerhaft sind und durch etwas anderes ersetzt werden könnten . Ich weiß nicht, ob ich das "Erweitern" oder eher "Verbessern" der Toolbox nennen würde :)
Andres F.
1
@AndresF. Das ist eine fantastische Lektüre. Ich habe vor, dieses Papier im Detail durchzugehen, wenn ich etwas Zeit habe.
Robert Harvey
4

Natürlich:

struct Foo
{
    string bar;
    int bux;
}

Ich weiß, was Sie sagen werden: "Aber das verkörpert nicht auch das Verhalten!" Nun, ich bin mit Joe Armstrong in dieser Sache: Sie können ganze Programme oder Betriebssysteme schreiben, ohne jemals erstklassige Objekte zu benötigen. Linux beweist das.

Javascript-Programmierer kapseln routinemäßig Status und Verhalten in Funktionen und Abschlüssen, nicht in Klassen.

Robert Harvey
quelle
3
Sie können auch Hügel von Schmutz mit nur Teelöffel schaufeln. Aber jeder, der behauptet, dies sei der optimale Weg, sollte mit Argwohn betrachtet werden.
Euphoric
6
Ich habe nie gesagt, dass es optimal ist, und das verlangt das OP sowieso nicht. In anderen Nachrichten finde ich es amüsant, dass Linux als Schaufeln von Schmutz mit einem Teelöffel qualifiziert ist.
Robert Harvey
2
@jk. Natürlich. So auch eine Art C.
Robert Harvey
1
in der Tat tut es irgendwie
jk.
4
Ich würde C-Strukturen nicht als "Kapselung" bezeichnen. Sie schützen weder die Daten noch bieten sie notwendigerweise standardisierte Methoden für den Zugriff darauf. Sie ersparen Ihnen nur die manuelle Zeigerarithmetik. Zum Beispiel ist es ziemlich üblich, Netzwerkcode zu finden, der serialisierte Pakete in Strukturen umwandelt und umgekehrt. Wenn Sie die Reihenfolge der Netzwerkbytes falsch festlegen, entsteht Spaß.
David25272
2

Das Hauptproblem hierbei ist, dass die Kapselung weder ein fest definiertes Konzept ist noch warum sie nützlich ist. Einige Untersuchungen zeigen, dass die Art und Weise, wie Menschen die Verkapselung sehen, eine hohe Meinung hat und dass viele Menschen sie mit Abstraktion verwechseln.

Die erste Definition, die Sie finden werden, ist

Kapselung ist ein Konzept, das die Daten und Funktionen, die die Daten manipulieren, miteinander verbindet ...

Wenn dies Ihre Definition ist, können die meisten Sprachen Daten und Funktionen, die mit diesen Daten arbeiten, in Klassen, Module, Bibliotheken, Namespaces usw. gruppieren.

Aber ich würde argumentieren, dass dies nicht der Hauptzweck der Kapselung ist, da diese Definition weitergeht:

... und das schützt sowohl vor Störungen von außen als auch vor Missbrauch.

Wikipedia stimmt auch darin überein :

Ein Sprachmechanismus zum Einschränken des direkten Zugriffs auf einige der Objektkomponenten.

Jetzt müssen wir uns fragen, was unter "Interferenz und Missbrauch" zu verstehen ist und warum der direkte Zugriff auf die Daten eingeschränkt werden sollte. Ich glaube, es gibt zwei Gründe.

Erstens liegt es im Interesse des Entwicklers, den Umfang zu beschränken, in dem Daten mutiert werden können. Viel zu oft muss vor dem Einstellen des Werts eine Logik vorhanden sein. Und nur eine begrenzte Anzahl von Stellen zu haben, an denen Wert festgelegt werden kann, ist äußerst wertvoll. In OOP-Sprachen kann dies mithilfe von Klassen erfolgen. In "veränderlichen" funktionalen Sprachen dienen Verschlüsse demselben Zweck. Und weil wir wissen, dass Klassen = Schließungen sind , ist es sogar fraglich, ob veränderbare funktionale Sprachen ein anderes "Paradigma" als OOP sind.

Aber was ist mit unveränderlichen Sprachen? Es hat kein Problem, Variablen zu mutieren. Hier kommt das zweite Problem ins Spiel: Durch Bindungsfunktionen und Daten können diese Daten in einem gültigen Zustand gehalten werden. Stellen Sie sich vor, Sie haben eine unveränderliche Struktur für Email. Diese Struktur hat ein einzelnes stringFeld. Wir haben Anforderungen, dass, wenn Sie einen Wert vom Typ haben, Emaildieses Feld eine gültige Adresse enthält. In der OOP-Kapselung kann dies leicht erreicht werden, indem dieses Feld deklariert privatewird, nur die GetMethode bereitgestellt wird undconstructor methodDies ist nur erfolgreich, wenn die als Zeichenfolge übergebene Adresse gültig ist. Ähnliches gilt für Verschlüsse. Für eine unveränderliche Sprache müsste man sagen, dass die Struktur nur durch eine bestimmte Funktion initialisiert werden kann und eine solche Funktion fehlschlagen kann. Und mir ist keine Sprache bekannt, die diesen Kriterien entspricht (vielleicht kann mich jemand in Kommentaren aufklären).

Letzte Ausgabe ist, was unter Sprache "Unterstützung" der Kapselung zu verstehen ist. Auf der einen Seite gibt es Sprachen, mit denen die Kapselung erzwungen werden kann, sodass der Code nicht kompiliert wird, wenn die Kapselung unterbrochen wird. Auf der anderen Seite bietet die Sprache möglicherweise eine Möglichkeit zur Kapselung, erzwingt sie jedoch nicht, sodass der Entwickler sie selbst erzwingen kann. Im zweiten Fall kann jede Sprache mit Strukturen und Funktionen funktionieren. Dynamische Sprachen und Haskell kommen mir in den Sinn. Und ich würde sagen, dass es nicht viele Sprachen gibt, die auf die andere Seite des Spektrums fallen. Sogar C #, das wirklich gut darin ist, die Kapselung für seine Objekte zu erzwingen, kann mithilfe von Reflexion umgangen werden. Aber zu sehen, dass in C # als massiver Code-Geruch angesehen wird, und kein vernünftiger C # -Entwickler würde dies bereitwillig tun.

Euphorisch
quelle