Hat Single-Paradigma OOP führt zur Abstraktion Inversion?

Question

Für diejenigen von Ihnen, die nicht vertraut mit dem Begriff sind, Abstraktion Inversion ist die Implementierung von Low-Level-Konstrukte auf der High-Level-Konstrukte, und wird in der Regel eine schlechte Sache betrachtet, weil es sowohl unnötige Komplexität und unnötige Overhead hinzufügt . Natürlich ist dies eine etwas ungenau, subjektive Definition ist.

Ihrer Meinung nach tut Programmierung in einer Single-Paradigma OOP-Sprache, in der alles muss Teil einer Klasse und Dinge wie Zeiger werden nicht ausgesetzt, wie Java oder C # sein, zwangsläufig zur Abstraktion Inversion führen? Wenn ja, in welchen Fällen?

Answer 1

Single-Paradigma alles verletzt das erste Gebot von Abstraktionen, die nur wenige Menschen scheinen zu wissen, und noch weniger kümmern uns um.

Du sollst nicht machen dir jede Abstraktion, die nicht bei Bedarf außer Kraft gesetzt werden kann, dass dein Code frei von hässlichen Abstraktion Inversionen sein.

Egal, was Ihr Paradigma, wenn Sie mit dem Schreiben nicht-trivialen Code starten reale Probleme zu lösen, können Sie mit einem paar Dingen zu Ende gehen, die einfach nicht das Paradigma sehr gut passen. Wenn Sie erklären, dass dass ein Paradigma ist alles da ist, das ist, wenn die Dinge hässlich.

ein paar Metaphern zu mischen, wenn alles, was Sie haben ein Hammer ist, beginnt alles wie ein Pflock zu sehen, und wenn alle Löcher rund sind und Sie plötzlich mit einigen Quadratklammern am Ende, und Sie haben keine Sägen, (nur Schlägel) Sie haben sich ein Problem.

Es gibt kein freies Mittagessen. Alles ist ein Kompromiss. Je einfacher Code wird zu schreiben, härter die es für jemand anderen zu lesen und zu pflegen, oder für Sie oder jemand anderes zu debuggen wird, wenn Probleme unterhalb der Ebene der Abstraktion auftreten, die Sie arbeiten, an. (Und sie wird schließlich, weil keine Abstraktion ist perfekt .

Dies ist der grundlegende Fehler mit „hilfreich“ Technologien und Paradigmen wie Managed Code, Garbage Collection, JIT-Kompilierung und dem „alles ein Objekt“ fiat. Sie verhängen eine Basisabstraktionsebene, die Sie nicht erlaubt sind unter zu erreichen, und wenn etwas unterhalb dieser Ebene schief geht, gibt es nichts, was man dagegen tun kann. Sie stecken arbeiten rund um eine schlechte Abstraktion, weil Sie es nicht beheben können.

Answer 2

real Programmierer kann Fortran in jeder Sprache schreiben

Mit anderen Worten, es ist nicht die Sprache, es ist der Programmierer

Answer 3

Java und C # haben statische Methoden, die Funktionen äquivalent sind, so wird die Sprache zwingt nichts auf Sie.

Wie gesagt, Wenn ich wirklich OO bekam, habe ich überhaupt keine Lust gehabt auf eine andere Art der Programmierung zu gehen.

Wenn Sie Ihre einfache OO Schicht etwas komplex bedeckt, schlage ich vor, dass es wahrscheinlich Ihr Code, der ein Problem ist. Wenn OO erfolgt Recht sollte es den ganzen Weg bis auf das Metall einfach sein.

Answer 4

Ich glaube nicht eine Sprache wie Java oder C # Darunter leidet in irgendeiner Art und Weise greifbar, einfach deshalb, weil die Bibliotheken den Rahmen begleitenden so reich sind, dass der Bedarf in ein anderes Paradigma zu brechen ist nicht wirklich für die allgemeine Programmierung erforderlich ist.

Das heißt, die reichen Bibliotheken können sich von der Abstraktion Inversion leiden jedoch, da die internen Implementierungen oft verborgen sind, oder Schlüsselklassen abgedichtet sind, versuchen Entwickler diese Bibliotheken erweitern oft in Wieder- gezwungen sind, Umsetzung / Funktionalität replizieren erfolgreich Verwendung von Erweiterungspunkten von der Basisklassenbibliothek zur Verfügung gestellt machen - das ist nicht so sehr ein Problem mit der Sprache, als eine bewusste Wahl durch den Entwickler der Basisklassenbibliotheken aus, Freilegung Funktionalität zu vermeiden, die spröde sind oder ändern sich oft mit neuen Versionen des .NET Framework / JDK.

Auch, weil das .Net Framework / Java Runtime sowohl für Interop mit anderen Sprachen erlaubt oben auf der gemeinsamen Laufzeit sitzen, die Fähigkeit, andere Paradigmen (wie funktionale Programmierung, dynamische Sprachen etc.) auch gezielt eine andere Route zu brechen bieten kann entfernt aus einem Paradigma Zwang.