Ist objektorientiertes Zeug wirklich so wichtig? [geschlossen]


8

Seit Jahren beschäftige ich mich mit algorithmischen Dingen, schreibe skalierbare Datenstrukturen für die Internetsuche, zum Beispiel Randomisierte binäre Suchbäume für die automatische Empfehlung, BitMaps, Wisdom of Crowd-basierte Algorithmen unter Verwendung von Grafiken, schreibe einige interessante Algorithmen für maschinelles Lernen wie Clustering, Anomalieerkennung, Arbeiten an Information Retrieval Sachen und so weiter

Es gibt eine gemeinsame Sache in den Dingen, die ich oben erwähnt habe. Alle oben genannten Dinge, wenn sie in einer Sprache wie C ++ codiert sind, erfordern eine Handvoll Klassen. Ich meine, es sind interessante Probleme, aber sie sind nicht komplex in Bezug auf stark geladene objektorientierte Dinge. Ich habe noch nie Vererbung, virtuelle Dinge usw. verwendet. Obwohl ich häufig generische Programmierung, Vorlagen usw. verwendet habe.

Ich liebe C ++ (- Sperriges OO-Zeug, wie mir gefällt, was Joe Armstrong, der Erfinder von Erlang, sagt: Wenn man in OO World nach einer Banane fragt, bekommt man einen großen Dschungel zusammen mit einem Gorilla, der die Banane hält). Ich programmiere gerne in anderen Sprachen wie Java und Python.

Meine Frage ist nun, da ich die Art von Projekten / Algorithmen genieße, an denen ich arbeite, muss ich wirklich OO-Sachen lernen. Werde ich ein besserer Programmierer / Designer sein, wenn ich nur Sachen wie Vererbung, dynamischer Polymorphismus (Virtuals) verwende? ODER kann ich in die Welt der funktionalen Programmierung wechseln (ich habe es bis jetzt noch nicht getan), was mich mehr anzieht, da ich mich nur auf Aufgaben / Algorithmen konzentrieren kann und nicht zulasse, dass auf Kingdom Of Noun basierendes OO-Zeug eine Regel ist mir?

Kurz gesagt, kann / kann mir OO-Zeug überhaupt bei der Art von Projekten / Algorithmen helfen, die ich oben erwähnt habe?

BEARBEITEN:

Ein äußerst interessanter Link, den Sie hier hinzufügen können:

http://steve-yegge.blogspot.in/2006/03/execution-in-kingdom-of-nouns.html


25
Objektorientierung ist heute das am weitesten verbreitete Programmierparadigma. Ignoriere es auf deine Gefahr.
Robert Harvey

5
<Sarkasmus> Nein, mach dir keine Sorgen. C sollte genug für Sie sein. </ Sarkasmus>
Otávio Décio

2
Verwandte / mögliche Duplikate: programmers.stackexchange.com/questions/7126/…
Adam Lear

16
Natürlich wird OOP / OOD überbewertet. Dieses triviale Modell kann nur für enge Problemgruppen verwendet werden. Aber Sie sollten es nicht ignorieren - sonst werden Sie die falschen Werkzeuge für die seltenen und engen Bereiche verwenden, in denen OOP wirklich glänzt.
SK-Logik

13
Linus Torvalds, bist du das?
Jesse C. Slicer

Antworten:


9

Objektorientierte Programmierung ist wirklich gut darin, Ihre komplexen mathematischen Dinge hinter leicht verständlichen Wörtern zu verstecken und es den Untergebenen unter Ihnen zu erleichtern, die von Ihnen geschriebenen Dinge tatsächlich zu verwenden. Es ersetzt nicht die funktionale Programmierung ... es gibt Ihnen nur eine wirklich einfache Möglichkeit, Implementierungen auszutauschen oder Verhalten hinzuzufügen.

Was wäre, wenn Sie in Ihrem obigen Beispiel für randomisierte binäre Suchbäume die Anforderung erhalten hätten, dass der Randomizer am Aprilscherz durch eine Reihenfolge nach Entfernung von drei Handlanger ersetzt wurde? Es ist sehr praktisch, StoogeBinaryTree : RandomBinaryTreedie protected int GetSortOrder (Tree a, Tree b)Methode zu erstellen und zu überschreiben. Am 2. April können Sie die Implementierung wieder auf die umstellen, RandomBinaryTreeohne diesen Code ändern zu müssen.

In einem einfachen Beispiel habe ich gezeigt, wie man sowohl winzige Verhaltensmerkmale hinzufügt als auch die Implementierung wechselt ...


14
Dies ist keine OOP, jedes anständige Modulsystem würde dasselbe tun (und wahrscheinlich auf viel einfachere Weise). Siehe zum Beispiel SML 1st Class Module.
SK-Logik

4
@ SK-Logik: Und Module und OOP unterscheiden sich signifikant, wie genau?
DeadMG

12
@DeadMG, es gibt keine BS über Zustände und Nachrichten und Vererbung in der Definition eines anständigen Modulsystems. Nur Einkapselung und eine Menge nützlicher Mathematik (ich weiß, dass Sie an diesem Punkt in Ohnmacht fallen werden).
SK-Logik

2
@ SK-Logik: Meine OOP-Systeme verwenden keine Nachrichten oder Vererbung oder übermäßigen Status. Sie kapseln, und wenn ich muss, können sie auch zur Laufzeit kapseln. Andere Leute mögen ihre natürlich anders machen, aber das ist ihre Wahl und nicht mit OOP.
DeadMG

3
@DeadMG Was ist dann der Unterschied zwischen einer objektorientierten und einer nicht orientierten Sprache? Inwiefern sind beispielsweise Haskell oder Erlang nicht objektorientiert, wenn für die Objektorientierung nur ein Modulsystem erforderlich ist? Oder sagen Sie, das sind objektorientierte Sprachen?
sepp2k

8

Wenn Sie FP immer noch mit Sprachen wie Haskell und Erlang machen wollen, die es gut können, müssen Sie die OOP-Kühlhilfe nicht trinken. FP ist sehr leistungsfähig und kann sogar in der realen Welt viel bewirken

Davon abgesehen wäre das Erlernen einer OOP-Sprache keine schlechte Sache. Das Verständnis mehrerer Programmiermethoden und verschiedener Methoden wird zu Ihren Gunsten funktionieren. Wenn Sie von Haskell oder Erlang nach Java wechseln, können Sie sich fragen, wie in aller Welt jeder ohne REPL und Lambdas arbeiten kann.


Und es sollte erwähnt werden, dass Sprachen wie Clojure OOP zulassen, Sie jedoch nicht darauf beschränken, klassenbasiert zu sein. Das heißt, Clojure unterstützt polymorphe Funktionen, Schnittstellen usw., ohne dass eine Klasse erstellt werden muss (zumindest nicht so, wie C # / Java sie definiert).
Timothy Baldridge

Joe Armstrong argumentiert, dass Erlang mehr OO ist als C ++ oder Java, sei nicht dogmatisch in diesen Dingen, sonst wirst du davon gebissen. Klicken Sie auf den Link @ Ist Erlang objektorientiert?

Oh, bin ich nicht, zum Teufel, ich habe ein Buch über Erlang geschrieben ( shop.oreilly.com/product/0636920021452.do ), aber wenn Leute über OOP sprechen, ist Erlang im Allgemeinen nicht das, was sie meinen
Zachary K

7

Es scheint, als hätten Sie sich immer nur auf die Lösung eines einzelnen Problems konzentriert, dh auf das Schreiben von Algorithmen. Überlegen Sie jedoch, wie Sie beispielsweise eine GUI-Anwendung oder eine andere große Anwendung schreiben würden, für die Sie möglicherweise einen Großteil Ihres Algorithmus verwenden müssen. In diesem Fall ist es wichtig, OO zu kennen, da es Ihnen hilft, Ihren Code zu vereinfachen, damit er für andere Entwickler besser lesbar und einfacher zu verwenden ist, z. B. indem Sie eine Bibliothek erstellen, die als Objekt geladen werden kann.

Eines der wichtigsten Entwurfsmuster in der objektorientierten Programmierung ist das Strategiemuster , das Ihnen im obigen Szenario ebenfalls sehr helfen wird. Stellen Sie sich ein Beispiel vor, in dem der Benutzer Ihnen Eingaben vorlegt, anhand derer der Benutzer einen Algorithmus ausführen kann. Dies kann leicht unordentlich sein, wenn / sonst oder Schalter / Gehäuse Konstruktion. Durch die Erstellung einer gemeinsamen Schnittstelle für Ihren Algorithmus und die Verwendung des Strategiemusters wäre Ihr Code viel flexibler, lesbarer, einfacher zu erweitern und somit einfacher zu warten.


Was sagen Sie zu funktionalen Sprachen, die das Strategiemuster ohne Objekte sehr elegant umsetzen (man könnte eher argumentieren)?
Steven Evers

4
-1 Für die Annahme, dass 1) große Anwendungen ohne OOP nicht möglich sind und 2) das Laden der Bibliothek in irgendeiner Weise mit OOP verbunden ist. Wenn Sie sich über Mehrfachversand (und das Ausdrucksproblem) informieren, werden Sie feststellen, dass Java / C # / C ++ tatsächlich viele Aufgaben erschwert, indem Sie dem Programmierer unnötige Einschränkungen auferlegen.
Timothy Baldridge

1
Bitte sagen Sie mir, wie eine Bibliothek, die als Objekt geladen werden könnte, besser ist als eine, die nicht als Objekt geladen wird.
Aseq

@ SnOrfus Ich befürworte OO, weil das die Welt ist, mit der ich am besten vertraut bin. Ich bin nicht vertraut mit funktionalen Sprachstrategie Muster
kba

2
"Strategiemuster" Das ist das Einzige, was mich an OOP mehr als alles andere verärgert. Warum muss alles ein Muster haben? Der einzige Grund, warum Dinge wie das Besuchermuster erfunden werden mussten, war, dass die verwendete Sprache so eingeschränkt und komplex war, dass es unmöglich war, eine Datenstruktur ohne Muster zu durchlaufen. Entfernen Sie die verrückte Komplexität moderner OOP-Sprachen und Muster plötzlich als einfache Funktionen. Muster sind einfach eine Möglichkeit, OOP so klingen zu lassen, als hätte es eine Ahnung, was es tut. </ Rant>
Timothy Baldridge

6

Der objektorientierte Ansatz wurde aufgrund eines entscheidenden Aspekts erfolgreich: Er ermöglicht es Ihnen, Systeme mit erheblicher wesentlicher Komplexität anzugehen, ohne zu viel zufällige Komplexität einzuführen . Dies kann fast ignoriert werden, wenn Sie an selbst entwickelten Systemen arbeiten, wird jedoch sehr wichtig, wenn Sie große Systeme erstellen.

Die Schlüsselelemente des objektorientierten Ansatzes können einem Programmierer mit umfassender Erfahrung in der prozeduralen Programmierung innerhalb weniger Tage erklärt werden, wodurch die Technik schnell an Popularität gewann (dies bedeutet nicht, dass Sie ein Experte in einem werden können Ein paar Tage: Es ist ähnlich wie beim Schachlernen - Sie können lernen, wie Sie Ihre Figuren in weniger als zehn Minuten bewegen, aber es dauert Jahre, um das Spiel zu meistern.

Funktionale Programmiertechniken gewinnen mit der Einführung der Sprachunterstützung in Mainstream-Sprachen (Lambdas und anonyme Delegierte von C #, Lambdas von C ++ und bis zu einem gewissen Grad sogar anonyme Java-Klassen) zunehmend an Bedeutung. Es ist sehr hilfreich, diese Techniken zu verstehen, aber sie wurden entwickelt, um lokalere Probleme auf taktischer Ebene anzugehen . Objektorientierte Techniken hingegen bleiben auf strategischer Ebene relevant , insbesondere im Kontext größerer Teams.


3
Während ich das in Bezug auf die Komplexität zum Ausdruck gebrachte Gefühl schätze, ist in der Praxis leider das Gegenteil der Fall. OO-Sprachen haben ein Händchen für unnötiges Aufblähen und Komplexität. Das ist oft nicht die Schuld der Sprache. Aber ich glaube, wenn eine Technik dazu neigt, so viele Menschen dazu zu bringen, sie falsch zu verwenden, kann sie etwas fehlerhaft sein. Egal wie schön es theoretisch klingt.
Aseq

1
+1 für dasblinkenlight und ich bin mit aseq nicht einverstanden. Insbesondere denke ich, dass OO genau dem entspricht, was für eine ereignisgesteuerte Benutzeroberfläche erforderlich ist, und da in der Benutzeroberfläche viel Aktivität vorhanden ist, gibt es in OO-Frameworks viel Aktivität. Wenn Sie eine Benutzeroberfläche ohne OO-Framework erstellen, wird am Ende etwas viel chaotischeres erstellt (siehe X11 Xt). Diese wesentliche Komplexität ist immer noch vorhanden, ohne den Rahmen, den sie auf schreckliche Weise hervorhebt. Verwenden Sie das richtige Werkzeug für den Job. Wenn ein ungelernter Praktizierender das falsche Werkzeug benutzt, beschuldigen Sie die Sprache oder den Praktizierenden?
Liudvikas Bukys

@aseq "Aber ich glaube, wenn eine Technik dazu neigt, so viele Menschen dazu zu bringen, sie falsch zu verwenden, kann sie etwas fehlerhaft sein." Das Betrachten der Rohzahlen ist irreführend, da unterschiedliche Technologien unterschiedliche Anzahlen von Praktikern anziehen . Prozentsätze wären etwas aussagekräftiger, aber sie sind nicht ohne weiteres verfügbar. Darüber hinaus halten Eintrittsbarrieren und die Struktur nichttechnologischer Anreize Praktiker mit unterschiedlichem Qualitätsgrad fern , sodass selbst Prozentsätze möglicherweise kein vollständiges Bild vermitteln.
Dasblinkenlight

1
Ich sehe nicht, dass funktionale Programmierung nicht "strategisch" ist. Es ist eher besser als OOP für größere Maßstäbe, da es die Kopplung und Komplexität reduziert und Sie auf einer höheren Abstraktionsebene arbeiten lässt. Es gibt auch einige sehr schöne Techniken, um Benutzeroberflächen auf rein funktionale Weise zu erstellen: Schauen Sie sich "funktionale reaktive Programmierung" an.
Tikhon Jelvis

4

Wenn Sie eine funktionale Programmierung durchführen, wird dies eine sehr gute Erfahrung für Sie sein, auch wenn Sie sich entscheiden, nicht fortzufahren. Wie Sie aus einigen Antworten hier lesen können, wissen viele Menschen nicht einmal, was es ist.

Konzepte für funktionale Sprachen, z. B. verzögerte Bewertung und referenzielle Transparenz, sind sehr, sehr gut zu lernen. Besonders wenn Sie Rekursion mögen.

zum Beispiel:

lenth :: [a] -> Integer
length (x:xs) = 1+length(xs)
length [] = 0

ist eine sehr einfache Haskell-Funktion, die eine Liste durchläuft und die Länge berechnet. Wenn Sie an Zahlen interessiert sind, die größer als lang sind, und unendliche Listen und andere ausgefallene Dinge verwenden möchten, probieren Sie die funktionale Programmierung aus.


2
Es ist auch eine dumme (manuelle Überquerung anstelle von vorgefertigten Abstraktionen und ineffiziente) Art der Implementierung length. Eine andere (effizientere und näher an der Art und Weise, wie nichttriviale FP-Programme tatsächlich geschrieben werden) Methode könnte darin bestehen, eine Falte mit Startwert 0und Schrittfunktion aufzurufen acc -> acc + 1. Alternativ sum . map (const 1)liest sich gut.

1
@Giorgio Nein, die Funktion ist nicht rekursiv. Und selbst wenn es so wäre, in Sprachen wie Haskell, die nur einen konkreten Zusammenhang mit Effizienz und Stack-Nutzung haben (man muss vermeiden, große Thunks zu bauen; weder dies noch ein lengthauf den nicht strengen folds gebautes tun dies).

2
@Jordan: Abgesehen davon, dass in Haskell, Werte können nicht geändert werden, und nicht alle Listen haben eine (endliche) Länge.
Jon Purdy

3
@ WalterMaier-Murdnelch Ja, die Liste muss irgendwann durchlaufen werden und man muss verstehen, was unter der Haube passiert. Aber das macht Abstraktionen nicht nutzlos, ganz im Gegenteil. Ich könnte SQL-Abfragen (über Yesods persistent), Fehlerbehandlung (über Maybe/ Either), Zustands-Jonglieren (über State), Baumdurchquerungen (über Map/ Set) usw. schreiben , aber meine Absicht in Bezug auf übergeordnete Funktionen zu beschreiben, ist in jeder Hinsicht besser und damit auch, was FP in der Praxis macht.

1
@Giorgio In strengen Sprachen, die immer noch die Norm sind, ist es - obwohl es auch vom Compiler abhängt, der sich um diese Optimierung kümmert (Python ist trotz einiger urbaner Mythen keine funktionale Sprache und optimiert keine Tail Calls - Lua OTOH tut). Sobald Sie jedoch nicht streng werden (bekanntestes Beispiel: Haskell), ändern sich die Regeln. Sie können schwanzrekursiv sein und trotzdem einen Stapelüberlauf erhalten, weil Sie einen riesigen Thunk aufgebaut haben (eine Million gestapelte Ganzzahladditionen, die aufgrund von Faulheit zurückgestellt wurden) oder (nicht schwanz-) rekursiv wild reinkommen und gut miteinander auskommen. Ich würde diese Regel also nicht als Evangelium betrachten.

2

Wie andere gesagt haben, ist Objektorientierung das vorherrschende Paradigma in der Industrie. Sie haben gesagt, dass Sie hauptsächlich mit Programmen gearbeitet haben, die von einer Handvoll Klassen angesprochen werden können, aber in einer industriellen Anwendung müssen Hunderte oder Tausende von Anwendungsfällen behandelt werden, und die Objektorientierung hat sich als sehr zuverlässig erwiesen und allgemein verständliche Möglichkeit, solche großen Codebasen zu strukturieren.

Sie sprechen von funktionaler Programmierung, die ein solider Anwärter auf The Next Big Paradigm ist, aber FP ist in der Industrie noch nicht vertraut. Insbesondere als C ++ - Programmierer sollten Sie wissen, dass die Industrie konservativ sein kann und die C / C ++ - Welt mit ihrem Schwerpunkt auf Leistung ein Ort ist, an dem die zwingende Natur der Hardware als eine sehr reale Überlegung angesehen wird. Im Allgemeinen stehen Programmierer eingebetteter Systeme meiner Erfahrung nach FP äußerst skeptisch gegenüber.

Auch wenn FP hat eine vorherrschende Paradigma in der Industrie worden, es ist sicherlich der Fall , dass es in Form von Objekt-funktionalen Hybridsprachen wie F # und Scala und nicht in Form von „reinen“ FP - Sprachen wie Haskell gelingen wird.

All dies bedeutet, dass objektorientiertes "Zeug" für professionelle Codebasen und Ihre Karriere wichtig ist.


2

OO gewann an Zugkraft, weil es eine große Verbesserung für den Umgang mit Komplexität darstellte, wie es zuvor auch die strukturierte / prozedurale Programmierung war.

Die Vorteile der Verwendung von OO nehmen mit zunehmender Größe des Projekts zu. Für ein 1KLOC-Programm spielt es keine Rolle, welches Paradigma Sie verwenden, alle funktionieren einwandfrei. Aber für ein 200KLOC + -Programm gibt es für OO einfach keine tragfähige Konkurrenz. Das bedeutet nicht, dass Sie kein 200KLOC-Programm in C schreiben können, sondern dass Sie viel disziplinierter sein müssen, um nicht in ein Chaos zu geraten, das niemand (nicht einmal Sie) verstehen kann. Das bedeutet nicht, dass OO ein solches Durcheinander verhindert, sondern dass es Ihr Leben leichter macht, um es zu verhindern.

Die funktionale Programmierung ist ein Paradigma, das etwas vom vorherigen Muster abweicht, da es nicht dazu beigetragen hat, noch komplexer als OO umzugehen, sondern eine andere Art von Problemen anzugehen: die parallele Programmierung. Dies war auch das erste Mal, dass ein Programmierparadigma dies versuchte: Alle Mechanismen, die zuvor in OO und / oder SP / PP existierten, waren nicht Teil des Paradigmas, sondern nur Betriebssystementitäten (Threads, Mutexe usw.). gekapselt nach den Paradigmenregeln.

In dieser Hinsicht ist FP viel natürlicher als die anderen, aber das geht zu Lasten der Umkehrung der Art und Weise, wie wir normalerweise über die Probleme denken. Aus diesem Grund verfügt es nur über eine begrenzte Kapazität, um dieselbe Komplexität in derselben Größenordnung wie OO zu bewältigen.

Ich vermute, dass dies die Einführung von FP in naher Zukunft auf sehr spezialisierte Systeme beschränken wird, im Allgemeinen nicht viel große oder spezialisierte Abschnitte größerer Systeme. Und der Rest wird weiterhin mit OO gemacht. Welche von denen Sie entwickeln möchten (oder etwas über die Entwicklung lernen), bestimmt, worauf Sie sich konzentrieren sollten, IMO.


1

Obwohl ich generische Programmierung, Vorlagen und so weiter stark verwendet habe.

Vorlagen sind wohl einfach eine andere Form von OOP. Virtuelle Funktionen und explizite Vererbung haben einen bestimmten Anwendungsfall - Laufzeit, binäre Austauschbarkeit. Vorlagen sind in der Kompilierungszeit austauschbar. Auf der einfachsten Ebene bieten sie jedoch die gleiche Feature-Abstraktion für jeden Typ, der die richtige Schnittstelle bietet. Die Überbeanspruchung der Laufzeitvererbung ist ein erheblicher Codegeruch, und in diesem Fall stimme ich Ihnen zu - sie wird für die meiste Zeit einfach nicht benötigt.

template<typename T> void func(T t) { t(5); }
void func(std::function<void(int)> t) { t(5); }

Diese beiden Snippets sind praktisch identisch, obwohl eines ausschließlich Vorlagen verwendet und das andere zur Vererbung Laufzeitvererbung und -klassen verwendet. Beide abstrahieren über die Funktion, die Sie aufrufen. Dies ist trivialerweise offensichtlich , wenn man Ersatz Tfür std::function<void(int)>, zum Beispiel. Der einzige Unterschied ist der Zeitpunkt, zu dem diese Abstraktion erfolgt. Die Vorlagenversion zeichnet sich durch Funktionen aus und std::functionist im Allgemeinen als Mitgliedsvariable besser geeignet. Sie möchten nicht jedes Mal eine neue Klasse erstellen müssen, wenn Sie einen neuen Rückruf wünschen.

OOP ist für Algorithmen nicht besonders gut geeignet. Es ist eher für groß angelegte Konstrukte gedacht, bei denen die Programmteile aufgeschlüsselt werden. Wenn Sie einen bestimmten Algorithmus schreiben, der mit bestimmten Daten arbeitet, ist es unwahrscheinlich, dass Sie Klassen benötigen.

Es ist einfach und großartig, Algorithmen für Funktionen zu erstellen. Sobald Sie jedoch darüber hinausgehen, werden Klassen zur dominierenden Methode.


9
Beeindruckend! Vorlagen sind eine "Form von OOP"? Du hast meinen Tag gemacht, Alter!
SK-Logik

4
Vorlagen sind für die generische Programmierung. Ich denke nicht, dass es richtig ist zu sagen, dass Vorlagen einfach eine andere Form von OOP sind. Hoffe, Alex Stepanov liest dies nicht :)
Yavar

Wie ich gezeigt habe, sind die beiden Funktionen praktisch gleichwertig und haben dieselbe Abstraktion. Es tritt einfach zu einer anderen Zeit auf.
DeadMG

4
Die heutige C ++ - Community verwendet Template-Metaprogrammierung für Dinge, die früher auf OOP-Weise erledigt wurden. Trotzdem würde ich dies nicht "eine andere Form von OOP" nennen. Insbesondere im obigen Beispiel würde ich "eine C ++ - Methode zur Verwendung von Funktorobjekten als spezielle Form der funktionalen Programmierung" nennen, was keine typische OOP-Lösung ist.
Doc Brown

4
Sie überlappen sich in einigen Merkmalen, richtig. Das liegt daran, dass sie beide nützlich sind, also gibt es unvermeidlich einige Dinge, die sie beide gut machen. Dies zeigt jedoch nicht , dass sie ständig isomorph sind, und es zeigt nicht, dass sie für alle Probleme gleichermaßen nützlich (z. B. prägnant und effizient) sind. Eine rein funktionale verknüpfte Liste teilt auch einige Funktionen mit dynamischen, überbelegten Arrays - beide sind geordnete Sammlungen, sie können mit angemessener Komplexität schrittweise erstellt werden, sie unterstützen die stapelartige Verwendung (Push / Pop / Peek) gut usw. unterscheiden sich aber stark, konzeptionell und in zahlreichen realen Anwendungen.

1

Ja, aus diesem Grund ist es wichtig: Wenn Sie OOP verstehen, werden Sie zu einem besseren Programmierer. Als Faustregel gilt: Verständnis macht Sie immer zu einem besseren Programmierer.

Es sollte beachtet werden, dass weder is-a noch Klassen, geschweige denn Vererbung, etwas mit OOP zu tun haben. Bei OOP geht es wirklich um die Entkopplung durch Indirektion, wie sie durch das Prinzip der Abhängigkeitsinversion formuliert wird . Man kann argumentieren, dass dies auch ein wichtiger Aspekt von FP ist. Wenn Sie sowohl OOP als auch FP studieren, werden Sie sich zunehmend bewusst, dass sie tatsächlich zwei Seiten eines Kontinuums sind. Je breiter und tiefer Ihr Verständnis davon ist, desto besser werden Sie.

Um ein Verständnis von OOP zu bekommen, versuchen Sie es mit Io und vielleicht Smalltalk und Ruby.


0

In der Entwicklungswelt sind Sprachen Werkzeuge, Programmierparadigmen Werkzeuge und Bibliotheken Werkzeuge. Je mehr Werkzeuge Sie haben, desto besser können Sie das richtige Werkzeug für den Job auswählen. Das würde also bedeuten, dass Sie OO, AOP und funktionale Programmierung lernen - wenn es die Zeit erlaubt.

Die Entwicklungswelt wird immer größer (in Bezug auf Sprachen, Frameworks usw.), sodass Sie nicht erwarten können, alles zu lernen. Ziel all dieser Innovationen ist es jedoch, Entwicklern zu mehr Produktivität zu verhelfen (Entwicklungsgeschwindigkeit und Wiederverwendbarkeit) und Code wartbarer zu machen (leichtes Verständnis, einfache Erweiterung und Änderung).

Das Beste, was Sie tun können, ist gezieltes, kontinuierliches Lernen in der Hoffnung, dass etwas Neues, das Sie gerade gelernt haben, Ihnen dabei geholfen hat, etwas besser und schneller auf eine Weise zu erledigen, die Sie nie erwartet hatten.


-1

Ich habe das Steve Jobs-Buch gelesen und dort ist eine Geschichte darüber, wie Steve SmallTalk in den Xerox PARC-Labors gesehen hat. Das war eine der frühesten OO-Sprachen. Ohne OO wäre es schrecklich gewesen, so etwas wie eine grafische Benutzeroberfläche (GUI) zu entwickeln. Mit all den asynchronen Eingaben und der Möglichkeit, von Aufgabe zu Aufgabe zu springen, während Sie mit dem einen oder anderen "Objekt" arbeiten.

Während Sie mit einer funktionalen Sprache viel anfangen können und sie definitiv ihre Anwendungsfälle hat. Wenn Sie sich mit komplexeren Systemen befassen, die stärker mit Problemen der realen Welt interagieren, ist OO ein überlegenes Design.


Das erste Macintosh-GUI-Framework (Toolbox) war ein schrecklicher Morast von C, der Win32 im Vergleich dazu vernünftig aussehen lässt. OO kam erst mit dem Wechsel zu OSX in die Mac-Welt! Dies ist eine schreckliche Analogie und bestenfalls historisch irreführend. Wings3D ist in Erlang geschrieben und verfügt über eine sehr umfangreiche Benutzeroberfläche. Es handelt sich um einen "realen", komplexen und praktischen Anwendungsfall, wie Sie ihn nur bekommen können.

Es verstärkt, dass funktionale Programmierung nicht gut dazu passte, nicht wahr? (Ich habe das Buch noch nicht fertiggestellt, interessant, dass sie sich nicht für einen der vielen Fortschritte des Xerox-Teams entschieden haben. Es klang, als wäre das Xerox-Team seiner Zeit weit voraus.)
Bill Leeper

Sie erkennen, dass Erlang eine funktionale Sprache ist und Wings3D eine sehr fortgeschrittene und komplizierte Benutzeroberfläche, die Ihrer Behauptung widerspricht, dass funktionale Programmierung nicht praktikabel und OO besser ist, was es nicht ist, es sei denn, Sie verstehen die Funktionstheorie nicht.
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.