Für welche Probleme ist objektorientierte Programmierung keine gute Wahl? [geschlossen]

Etwas inspiriert von dieser Frage: Für welche häufigen Probleme passt die funktionale Programmierung nicht? - aber trotzdem eine Frage, die ich immer wollte, aber zu ängstlich zu stellen war.

Ich war in ... naja, nennen wir es Engineering-Software-Entwicklung praktisch mein ganzes Leben lang, und in der ganzen Zeit, obwohl OO immer da war (naja, die meiste Zeit), hatte ich nie das Bedürfnis, es zu benutzen "seine Wege", noch dieses Paradigma zu lernen. Wir haben immer eher einfache Programmstrukturen, Routinen / Funktionen / Module verwendet, und obwohl dies den heutigen Best Practices für die Verwaltung dieser Programme (Programme mit einer Größe von bis zu 300 KByte, nichts zu groß) zuwiderläuft, hat es sich nie als schwierig oder gar unmöglich erwiesen.

Ich wollte Sie also fragen, was für ein Problem das sein könnte, für das ein objektorientiertes Paradigma keine gute Wahl wäre. Im Vergleich zur prozeduralen Programmierung?

Objektorientierte Programmierung ist prozedurale Programmierung. Das, was OO objektorientiert macht, ist, wie Robert Harvey in einem Kommentar erwähnt, dass OO Daten auf eine bestimmte Art und Weise abstrahiert (dh die Funktionen, die an einer Struktur arbeiten, mit dieser Struktur bündelt).

William Cook erklärt den Unterschied zwischen Objekten und abstrakten Datentypen sehr gut.

Bei der Gefahr, einfach zu klingen, würde ich sagen, dass Objekte nicht gut geeignet sind, wenn Sie die (Anzahl) der Operationen, die mit Ihren Daten ausgeführt werden, einfach erweitern müssen und keine unterschiedlichen Implementierungen Ihrer Daten benötigen Daten. Trotzdem gibt es Dinge, die Sie tun können , um die beiden näher zusammenzubringen.

Der Hauptvorteil von OO besteht darin, dass es eine Entkopplung zwischen den Komponenten Ihres Systems ermöglicht, wodurch es einfacher wird, DRY-Code zu schreiben und sich an bestimmte Arten von Änderungen anzupassen, die Sie in Ihrem Entwurf planen. Die Kosten bestehen darin, dass zusätzliche Indirektionsebenen hinzugefügt werden, wodurch der Code schwerer nachzuvollziehen ist, weniger effizient ist und auf unerwartete Weise weniger modifiziert werden kann (die Art und Weise, die nicht durch die Entkopplung unterstützt wird, die Ihr Design bietet). Es ist daher Zeitverschwendung für Teilprobleme, bei denen Sie die damit verbundene Entkopplung nicht benötigen. Insbesondere ist es Zeitverschwendung, wenn Sie DRY-Code problemlos ohne ihn schreiben können und keine spezifischen Anforderungsänderungen erwarten , die von der starken Entkopplung profitieren würden, die OO bietet.

Parallelität: Der Sperrmechanismus scheint problematisch zu sein. Nur einige sehr gute Entwickler arbeiten am Threading-Teil von Projekten

Erweitern: Ich weiß nicht, wie erweiterbar die aktuellen OO-Sprachen sind. nur wissen, dass Java schlecht ist. Dafür müssen DSLs (domänenspezifische Sprachen) als Frameworks implementiert werden. Clojure hingegen (das ist funktional) hat Makros.

Die meisten Programmierer, ob versiert oder nicht, verwenden Konzepte wie Abstraktion, Verstecken von Informationen und Schnittstellen in ihrem Code. OO-Sprachen machen das einfach einfacher, da diese Konzepte bereits integriert sind. Sie müssen sie nicht selbst erfinden.

Ein Kernalgorithmus wie qsort()verwendet Abstraktionen zum Vergleich beliebiger Objekte. fread()verwendet eine Schnittstelle, um die Details des Streams usw. zu abstrahieren.

Unter diesem Gesichtspunkt fällt es mir schwer, ein bestimmtes Problem zu finden, das besser mit einem Nicht-OO-Ansatz gelöst werden kann.

Ich denke, wenn Sie Systeme erstellen, die andere Systeme über Web-APIs kombinieren (rest, xmlprc, plain curl / wget), können Sie OO-Wrapper schreiben, aber das ist eindeutig nur eine Annehmlichkeit. Wenn der zu verwendende Webdienst einfach ist und es sich nur um ein oder zwei Zeilen handelt, ist OO zu viel. Wenn Sie andererseits eine komplexe Web-API (wie z. B. Amazon AWS) einbinden müssen, ist eine Wrapper-Bibliothek (wie boto in Python für AWS) hilfreich.

Gedanken?

Die objektorientierten PURE-Sprachen sind in vielen Fällen nicht geeignet. Weil einige Kriterien erfüllt sein müssen, um eine reine objektorientierte Sprache zu sein. Siehe
/programming/250062/what-is-meant-the-term-true-object-orientation/250098#250098

Die am häufigsten verwendeten Programmiersprachen sind jedoch multiparadigmatisch. Sie enthalten viele Nicht-OO-Funktionen, um verschiedene Arten von Programmier- und Entwicklungsproblemen zu lösen. C ++, C #, Java oder Ruby verfügen alle über Nicht-OO-Funktionen. Sie können sich also Problemen stellen, in denen pure-OO nicht gut ist.

Objektorientierte Programmierung kann verwendet werden, um Ihre Domäne zu modellieren. Die Klassen können verwendet werden, um den Status und das Verhalten von Entitäten, Aggregaten, Kollaborationen und Diensten innerhalb Ihres Domänenmodells darzustellen. Darüber hinaus können die Methodenaufrufe und Protokolle zwischen den Objekten die dynamischen Beziehungen zwischen Entitäten modellieren.

Ich habe festgestellt, dass dies eine nützliche Methode ist, um ein DRY - Modell zu erstellen, das die Regeln und das Verhalten Ihrer Anwendung sauber und unabhängig von technischen Problemen (z. B. der Verwendung einer Datenbank, einer Nachrichtenwarteschlange oder der Systemverwaltung) darstellt Tatsache ist, dass es sich um eine Webanwendung handelt). Ein gutes Buch zum Thema ist Domain Driven Design

Eine wichtige Sache, die hier beachtet werden muss, ist, dass die oben erwähnten "Entitäten" nicht auf Objekte der realen Welt abgebildet werden müssen! Sie können abstrakte Teile der Domäne Ihrer Anwendung darstellen.

Also, wenn dies das ist, wozu objektorientierte Programmierung gut ist; was ist nicht gut in Nun, alles, wo das Domänenmodell nicht gut ausgedrückt werden kann, als Objekte. Einige mathematische, (statistische, logische usw.) oder technische Programme (z. B. ein Compiler) lassen sich in verschiedenen Stilen besser ausdrücken. Ich habe festgestellt, dass für Business-Workflow-Anwendungen eine Kombination aus OO- und benutzerdefinierten DSL-Techniken sehr effektiv ist, um die Arten von Beziehungen und Ereignissen zu modellieren, die in Geschäftsprozessen auftreten. Zur Programmüberprüfung und automatisierten Proofprüfung wird häufig ein funktionaler Ansatz verwendet, da seine reinen Funktionen direkteres mathematisches Denken ermöglichen.