Wann ist OOP besser geeignet?[geschlossen]

StackOverflow https://stackoverflow.com/questions/6703

  •  08-06-2019
  •  | 
  •  

Frage

Seit ich angefangen habe, objektorientierte Programmierung zu studieren, lese ich häufig Artikel/Blogs, in denen es heißt, dass Funktionen besser seien oder nicht alle Probleme als Objekte modelliert werden sollten.Wann lässt sich bei Ihren persönlichen Programmierabenteuern Ihrer Meinung nach ein Problem besser durch OOP lösen?

War es hilfreich?

Lösung

Es gibt keine feste Regel.Ein Problem lässt sich mit OOP besser lösen, wenn Sie besser darin sind, Probleme zu lösen und in einer OO-Mentalität zu denken.Objektorientierung ist nur ein weiteres Werkzeug, das durch den Versuch entstanden ist, Computer zu einem besseren Werkzeug zur Lösung von Problemen zu machen.

Es kann jedoch eine bessere Wiederverwendung von Code ermöglichen und auch zu einem übersichtlicheren Code führen.Aber oft sind diese hochgelobten Eigenschaften in Wirklichkeit von geringem wirklichen Wert.Die Anwendung von OO-Techniken auf eine bestehende funktionale Anwendung könnte tatsächlich viele Probleme verursachen.Die Fähigkeit besteht darin, viele verschiedene Techniken zu erlernen und die für das jeweilige Problem am besten geeignete anzuwenden.

OO wird oft als Nirvana-ähnliche Lösung für die Softwareentwicklung bezeichnet, es kommt jedoch häufig vor, dass die Anwendung auf das vorliegende Problem nicht angemessen ist.Dies kann häufig dazu führen, dass ein Problem übermäßig überarbeitet wird, um die perfekte Lösung zu finden, obwohl dies oft gar nicht notwendig ist.

Im Wesentlichen handelt es sich bei OOP nicht wirklich um objektorientierte Programmierung, sondern um die Zuordnung von objektorientiertem Denken zu einer Programmiersprache, die OO-Techniken unterstützen kann.OO-Techniken können von Sprachen unterstützt werden, die nicht von Natur aus OO sind, und es gibt Techniken, die Sie innerhalb funktionaler Sprachen verwenden können, um von den Vorteilen zu profitieren.

Beispielsweise entwickle ich seit etwa 20 Jahren OO-Software, daher neige ich dazu, beim Lösen von Problemen in OO-Begriffen zu denken, unabhängig von der Sprache, in der ich schreibe.Derzeit implementiere ich Polymorphismus mit Perl 5.6, das ihn nicht nativ unterstützt.Ich habe mich dafür entschieden, da dadurch die Wartung und Erweiterung des Codes zu einer einfachen Konfigurationsaufgabe und nicht zu einem Entwicklungsproblem wird.

Ich bin mir nicht sicher, ob das klar ist.Es gibt Leute, die im OO-Gericht hart sind, und es gibt Leute, die im Funktionsgericht hart sind.Und dann gibt es Leute, die beides ausprobiert haben und versuchen, aus jedem das Beste herauszuholen.Keiner von beiden ist perfekt, aber beide haben einige sehr gute Eigenschaften, die Sie unabhängig von der Sprache nutzen können.

Wenn Sie OOP erlernen möchten, konzentrieren Sie sich nicht nur auf OOP, sondern versuchen Sie, die objektorientierte Analyse und allgemeine OO-Prinzipien auf das gesamte Spektrum der Problemlösung anzuwenden.

Andere Tipps

Ich bin zwar ein Oldtimer, programmiere aber auch schon lange OOP.Ich persönlich bin dagegen, OOP nur zu nutzen, um es zu nutzen.Ich bevorzuge, dass Objekte einen bestimmten Grund für ihre Existenz haben, dass sie etwas Konkretes modellieren und dass sie einen Sinn ergeben.

Das Problem, das ich bei vielen neueren Entwicklern habe, ist, dass sie keine Vorstellung davon haben, welche Ressourcen sie mit dem von ihnen erstellten Code verbrauchen.Wenn Sie große Datenmengen verarbeiten und auf Datenbanken zugreifen, ist das „perfekte“ Objektmodell möglicherweise das Schlimmste, was Sie für Leistung und Ressourcen tun können.

Mein Fazit lautet: Wenn es als Objekt sinnvoll ist, dann programmieren Sie es als Objekt, solange Sie die Auswirkungen der Implementierung Ihres Objektmodells auf Leistung/Ressourcen berücksichtigen.

Ich denke, es passt am besten, wenn Sie etwas modellieren, das mit dem Zustand und den damit verbundenen Aktionen für diese Zustände zusammenhängt.Ich denke, das ist etwas vage, aber ich bin mir nicht sicher, ob es hier eine perfekte Antwort gibt.

Das Besondere an OOP ist, dass Sie damit Daten und Informationen kapseln und abstrahieren können, was beim Aufbau eines großen Systems ein echter Segen ist.Sie können das Gleiche auch mit anderen Paradigmen tun, aber es scheint, dass OOP in dieser Kategorie besonders hilfreich ist.

Es hängt auch etwas von der Sprache ab, die Sie verwenden.Wenn es sich um eine Sprache mit umfangreicher OOP-Unterstützung handelt, sollten Sie diese wahrscheinlich zu Ihrem Vorteil nutzen.Wenn dies nicht der Fall ist, müssen Sie möglicherweise andere Mechanismen finden, um das Problem in kleinere, leicht testbare Teile aufzuteilen.

Ich bin an OOP verkauft.

Immer wenn Sie ein Konzept für ein Problem definieren können, kann es wahrscheinlich in ein Objekt eingeschlossen werden.

Das Problem mit OOP besteht darin, dass einige Leute es überbeanspruchen und ihren Code noch schwieriger verständlich machen.Wenn Sie sorgfältig darauf achten, was Sie in Objekte und was in Dienste (statische Klassen) einfügen, werden Sie von der Verwendung von Objekten profitieren.

Fügen Sie einfach nichts in das Objekt ein, das nicht zu einem Objekt gehört, denn Sie möchten, dass Ihr Objekt etwas Neues tut, an das Sie ursprünglich nicht gedacht haben. Führen Sie eine Umgestaltung durch und finden Sie den besten Weg, diese Funktionalität hinzuzufügen.

Es gibt fünf Kriterien, ob Sie objektorientierten Code gegenüber objektbasiertem, funktionalem oder prozeduralem Code bevorzugen sollten.Denken Sie daran, dass alle diese Stile in allen Sprachen verfügbar sind Stile.All dies ist im Stil von „Soll ich in dieser Situation OO bevorzugen?“ geschrieben.

Das System ist sehr komplex und hat über etwa 9.000 LOC (einfach ein beliebiges Level).- Je komplexer die Systeme werden, desto größer werden die Vorteile, die sich aus der Kapselung der Komplexität ergeben.Im Gegensatz zu den anderen Techniken tendiert man bei OO dazu, immer mehr von der Komplexität einzukapseln, was auf dieser Ebene sehr wertvoll ist.Zuvor sollten objektbasiert oder prozedural bevorzugt werden.(Das befürwortet wohlgemerkt keine bestimmte Sprache.) OO C passt meiner Meinung nach besser zu diesen Funktionen als OO C++, eine Sprache mit einem berüchtigten Ruf für undichte Abstraktionen und der Fähigkeit, Läden mit selbst einem mittelmäßigen/hartnäckigen Programmierer zum Mittagessen zu fressen.

Bei Ihrem Code handelt es sich nicht um Operationen an Daten (d. h.Datenbankbasiert oder mathematisch/analysebasiert.Datenbankbasierter Code lässt sich häufig einfacher über einen prozeduralen Stil darstellen.Analysebasierter Code lässt sich oft einfacher in einem funktionalen Stil darstellen.

Ihr Modell ist eine Simulation von etwas (OO zeichnet sich durch Simulationen aus).

Sie tun etwas, für das der objektbasierte Subtyp-Versand von OO wertvoll ist (d. h. Sie müssen eine Nachricht an alle Objekte eines bestimmten Typs und verschiedener Subtypen senden und von allen eine angemessene, aber unterschiedliche Reaktion erhalten). .

Ihre App ist nicht multithreaded, insbesondere nicht in einer Codebasis vom Typ „Nicht-Worker-Aufgabenmethode“.OO ist in Programmen mit mehreren Threads, die unterschiedliche Threads für unterschiedliche Aufgaben benötigen, recht problematisch.Wenn Ihr Programm mit einem oder zwei Hauptthreads und vielen Worker-Threads strukturiert ist, die dasselbe tun, ist der verworrene Kontrollfluss von OO-Programmen einfacher zu handhaben, da alle Worker-Threads in dem, was sie berühren, isoliert sind und als solche betrachtet werden können ein monolithischer Codeabschnitt.Betrachten Sie tatsächlich jedes andere Paradigma.Functional zeichnet sich durch Multithreading aus (das Fehlen von Nebenwirkungen ist ein großer Segen), und die objektbasierte Programmierung kann Ihnen mit der Kapselung von OO Vorteile verschaffen, jedoch mit besser nachvollziehbarem prozeduralem Code in kritischen Abschnitten Ihrer Codebasis.Auch in diesem Bereich ist die verfahrenstechnische Vorgehensweise natürlich hervorragend.

An einigen Stellen, an denen OO nicht so gut ist, handelt es sich um „Datensätze“ wie in SQL.OO macht mengenbasierte Operationen tendenziell schwieriger, da es nicht wirklich darauf ausgelegt ist, den Schnittpunkt zweier Mengen oder die Obermenge zweier Mengen optimal zu erfassen.

Außerdem gibt es Zeiten, in denen ein funktionaler Ansatz sinnvoller wäre, wie in diesem Beispiel MSDN:

Denken Sie beispielsweise daran, ein Programm zu schreiben, um ein XML-Dokument in eine andere Datenform zu konvertieren.Während es sicherlich möglich wäre, ein C#-Programm zu schreiben, das das XML-Dokument analysiert und verschiedene if-Anweisungen anwendet, um zu bestimmen, welche Aktionen an verschiedenen Stellen im Dokument ausgeführt werden sollen, besteht ein wohl überlegener Ansatz darin, die Transformation als eXtensible Stylesheet zu schreiben Programm zur Sprachtransformation (XSLT).Es überrascht nicht, dass XSLT einen großen Teil des Funktionalismus in sich trägt

Ich finde, dass es hilfreich ist, ein bestimmtes Problem in Form von „Dingen“ zu betrachten.

Wenn man sich das Problem so vorstellen kann, dass es ein oder mehrere „Dinge“ gibt, wobei jedes „Ding“ eine Reihe von Attributen oder Informationen hat, die sich auf seinen Zustand beziehen, und eine Reihe von Operationen, die an ihm ausgeführt werden können – dann ist OOP ist wahrscheinlich der richtige Weg!

Der Schlüssel zum Erlernen der objektorientierten Programmierung liegt im Erlernen von Entwurfsmustern.Durch das Kennenlernen von Entwurfsmustern können Sie besser erkennen, wann Klassen benötigt werden und wann nicht.Wie alles andere in der Programmierung hängt auch die Verwendung von Klassen und anderen Funktionen von OOP-Sprachen von Ihrem Design und Ihren Anforderungen ab.Wie Algorithmen sind Entwurfsmuster ein Konzept höherer Ebene.

Ein Entwurfsmuster spielt eine ähnliche Rolle wie Algorithmen für traditionelle Programmiersprachen.Ein Entwurfsmuster zeigt Ihnen, wie Sie Objekte erstellen und kombinieren, um eine nützliche Aufgabe auszuführen.Wie die besten Algorithmen sind auch die besten Entwurfsmuster allgemein genug, um auf eine Vielzahl häufiger Probleme angewendet zu werden.

Meiner Meinung nach geht es eher um Sie als Person.Manche Menschen denken besser in funktionalen Begriffen, andere bevorzugen Klassen und Objekte.Ich würde sagen, dass OOP besser geeignet ist, wenn es Ihrem internen (subjektiven) mentalen Modell der Welt entspricht.

Objektorientierter Code und prozeduraler Code haben unterschiedliche Erweiterungspunkte.Objektorientierte Lösungen erleichtern das Hinzufügen neuer Klassen, ohne vorhandene Funktionen zu ändern (siehe das Open-Closed-Prinzip), während prozeduraler Code das Hinzufügen von Funktionen ermöglicht, ohne vorhandene Datenstrukturen zu ändern.Sehr oft erfordern unterschiedliche Teile eines Systems unterschiedliche Ansätze, abhängig von der Art der erwarteten Änderung.

OO ermöglicht die Platzierung der Logik, die sich auf ein Objekt bezieht, an einem einzigen Ort (der Klasse oder dem Objekt), sodass sie entkoppelt und einfacher zu debuggen und zu warten ist.

Was ich beobachtet habe, ist, dass jede App eine Kombination aus OO und prozeduralem Code ist, wobei der prozedurale Code der Klebstoff ist, der alle Ihre Objekte zusammenhält (zumindest der Code in Ihrer Hauptfunktion).Je mehr Sie Ihren prozeduralen Code in OO umwandeln können, desto einfacher wird es, Ihren Code zu pflegen.

Warum OOP zum Programmieren verwendet wird:

  1. Seine Flexibilität – OOP ist hinsichtlich der Verwendungsimplementierungen wirklich flexibel.
  2. Es kann Ihre Quellcodes um mehr als 99,9 % reduzieren – es klingt vielleicht, als würde ich übertreiben, aber es ist wahr.
  3. Es ist viel einfacher, Sicherheit zu implementieren – Wir alle wissen, dass Sicherheit eine der wichtigsten Anforderungen bei der Webentwicklung ist.Die Verwendung von OOP kann die Sicherheitsimplementierungen in Ihren Webprojekten vereinfachen.
  4. Dadurch wird die Codierung besser organisiert. Wir alle wissen, dass ein sauberes Programm eine saubere Codierung ist.Durch die Verwendung von OOP statt prozedural werden die Dinge (offensichtlich) besser organisiert und systematisiert.
  5. Es hilft Ihrem Team, problemlos zusammenzuarbeiten – ich weiß, dass einige von Ihnen Teamprojekte hatten/erlebt haben und einige von Ihnen wissen, dass es wichtig ist, die gleichen Methoden, Implementierungen, Algorithmen usw. usw. usw. zu haben

Es kommt auf das Problem an:Das OOP-Paradigma ist nützlich beim Entwerfen verteilter Systeme oder Frameworks, bei denen viele Entitäten während der Aktionen des Benutzers leben (Beispiel:Internetanwendung).

Wenn Sie jedoch ein mathematisches Problem haben, bevorzugen Sie eine funktionale Sprache (LISP).Für leistungskritische Systeme verwenden Sie ADA oder C usw. usw.

Die Sprache OOP ist nützlich, weil sie wahrscheinlich auch den Garbage Collector (automatische Speichernutzung) im Programmablauf verwendet:Wenn Sie in C programmieren, müssen Sie viel Zeit mit dem Debuggen und manuellen Beheben eines Speicherproblems verbringen.

OOP ist nützlich, wenn Sie Dinge haben.Ein Socket, eine Schaltfläche, eine Datei.Wenn Sie eine Klasse mit „er“ beenden, ist es fast immer eine Funktion, die vorgibt, eine Klasse zu sein.TestRunner sollte höchstwahrscheinlich eine Funktion sein, die Tests ausführt (und wahrscheinlich Run-Tests nennt).

Persönlich denke ich, dass OOP praktisch eine Notwendigkeit für jede große Anwendung ist.Ich kann mir nicht vorstellen, ein Programm mit mehr als 100.000 Codezeilen ohne die Verwendung von OOP zu haben, das wäre ein Wartungs- und Design-Albtraum.

Ich sage dir, wann OOP schlecht ist.

Wenn der Architekt wirklich komplizierten, nicht dokumentierten OOP-Code schreibt.Verlässt das Projekt zur Hälfte.Und bei vielen seiner gemeinsamen Codeteile, die er in verschiedenen Projekten verwendet hat, fehlt Code.Gott sei Dank für .NET Reflector.

Und die Organisation nutzte weder Visual Source Safe noch Subversion.

Und es tut mir Leid.2 Seiten Code zum Anmelden sind ziemlich lächerlich, auch wenn er niedlich OOPed ist ...

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top