Was ist der Sinn von OOP?

https://stackoverflow.com/questions/24270

09-06-2019
|

Frage

Soweit ich das beurteilen kann, hat OOP trotz der unzähligen Millionen oder Milliarden, die für OOP-Schulung, -Sprachen und -Tools ausgegeben wurden, weder die Entwicklerproduktivität oder Softwarezuverlässigkeit verbessert noch die Entwicklungskosten gesenkt.Nur wenige Menschen verwenden OOP in einem strengen Sinne (nur wenige Menschen befolgen oder verstehen Prinzipien wie LSP);Die Ansätze zur Modellierung von Problembereichen scheinen wenig einheitlich oder konsistent zu sein.Allzu oft wird die Klasse nur wegen ihres syntaktischen Sinns verwendet;Es fügt die Funktionen für einen Datensatztyp in ihren eigenen kleinen Namensraum ein.

Ich habe eine große Menge Code für eine Vielzahl von Anwendungen geschrieben.Obwohl es Stellen gab, an denen echte substituierbare Subtypen eine wertvolle Rolle in der Anwendung spielten, waren diese eher außergewöhnlich.Im Allgemeinen gibt es zwar viele Lippenbekenntnisse zur „Wiederverwendung“, die Realität ist jedoch so, es sei denn, ein Teil des Codes tut dies genau Was Sie damit erreichen wollen, ist eine kostengünstige „Wiederverwendung“ kaum möglich.Es ist äußerst schwierig, Klassen erweiterbar zu gestalten auf die richtige Art und Weise, Daher sind die Kosten für die Erweiterung normalerweise so hoch, dass sich eine „Wiederverwendung“ einfach nicht lohnt.

In vielerlei Hinsicht überrascht mich das nicht.Die reale Welt ist nicht „OO“, und die in OO enthaltene Idee – dass wir Dinge mit einer Klassentaxonomie modellieren können – scheint mir grundlegend fehlerhaft zu sein (ich kann auf einem Tisch, einem Baumstumpf, einer Autohaube sitzen). , jemandes Schoß – aber keiner davon ist ein Stuhl).Selbst wenn wir uns abstrakteren Bereichen zuwenden, ist die OO-Modellierung oft schwierig, kontraintuitiv und letztendlich nicht hilfreich (denken Sie an die klassischen Beispiele von Kreisen/Ellipsen oder Quadraten/Rechtecken).

Was fehlt mir also hier?Wo liegt der Wert von OOP und warum ist es trotz all der Zeit und des Geldes nicht gelungen, Software besser zu machen?

Lösung

Es gibt keine empirischen Beweise dafür, dass Objektorientierung für Menschen eine natürlichere Art ist, über die Welt nachzudenken.Es gibt einige Arbeiten auf dem Gebiet der Programmierpsychologie, die zeigen, dass OO nicht irgendwie passender ist als andere Ansätze.

Objektorientierte Darstellungen scheinen nicht allgemein verwendbarer oder weniger verwendbar zu sein.

Es reicht nicht aus, einfach OO-Methoden zu übernehmen und von den Entwicklern zu verlangen, solche Methoden zu verwenden, da dies negative Auswirkungen auf die Entwicklerproduktivität sowie auf die Qualität der entwickelten Systeme haben könnte.

Das ist aus „On the Usability of OO Representations“ aus Communications of the ACM Okt.2000.In den Artikeln wird hauptsächlich OO mit dem prozessorientierten Ansatz verglichen.Es gibt zahlreiche Studien darüber, wie Menschen, die mit der OO-Methode arbeiten, „denken“ (Int.J.of Human-Computer Studies 2001, Ausgabe 54, oder Human-Computer Interaction 1995, Bd.10 hat ein ganzes Thema zu OO-Studien), und nach dem, was ich gelesen habe, deutet nichts auf eine gewisse Natürlichkeit des OO-Ansatzes hin, die ihn besser geeignet machen würde als einen traditionelleren prozeduralen Ansatz.

Andere Tipps

Die reale Welt ist nicht „OO“, und die in OO enthaltene Idee – dass wir Dinge mit einer Klassentaxonomie modellieren können – scheint mir grundlegend fehlerhaft zu sein

Während dies wahr ist und von anderen Leuten beobachtet wurde (z. B. Stepanov, Erfinder des STL), ist der Rest Unsinn.OOP mag fehlerhaft sein und sicherlich kein Allheilmittel, aber es macht umfangreiche Anwendungen viel einfacher, weil es eine großartige Möglichkeit ist, Abhängigkeiten zu reduzieren.Dies gilt natürlich nur für „gutes“ OOP-Design.Ein schlampiges Design bringt keinen Vorteil.Aber ein gutes, entkoppeltes Design lässt sich mit OOP sehr gut modellieren, mit anderen Techniken jedoch nicht so gut.

Es gibt viel bessere, universellere Modelle (Haskells Typmodell (das fällt mir ein), aber diese sind oft auch komplizierter und/oder schwieriger effizient umzusetzen.OOP ist ein guter Kompromiss zwischen Extremen.

Bei OOP geht es nicht um die Erstellung wiederverwendbarer Klassen, sondern um die Erstellung verwendbarer Klassen.

Allzu oft wird die Klasse einfach für ihren syntaktischen Zucker verwendet.Es bringt die Funktionen für einen Datensatztyp in ihren eigenen kleinen Namespace.

Ja, ich finde das auch zu häufig.Dies ist keine objektorientierte Programmierung.Es handelt sich um objektbasierte Programmierung und datenzentrierte Programmierung.In meinen 10 Jahren, in denen ich mit OO Languages arbeite, sehe ich Leute, die sich hauptsächlich mit objektbasierter Programmierung befassen.OBP bricht meiner Meinung nach sehr schnell zusammen, da Sie im Wesentlichen das Schlimmste beider Wörter verstehen:1) Prozedurale Programmierung ohne Einhaltung der bewährten strukturierten Programmiermethodik und 2) OOP ohne Einhaltung der bewährten OOP-Methodik.

OOP richtig gemacht ist eine schöne Sache.Dadurch lassen sich sehr schwierige Probleme leicht lösen, und für den Uneingeweihten (ich möchte hier nicht aufgeblasen klingen) kann es fast wie Magie wirken.Abgesehen davon ist OOP nur ein Werkzeug im Werkzeugkasten der Programmiermethoden.Es ist nicht die ultimative Methode.Es eignet sich einfach gut für große Geschäftsanwendungen.

Die meisten Entwickler, die in OOP-Sprachen arbeiten, verwenden Beispiele für OOP, die direkt in den Frameworks und Typen umgesetzt werden, die sie täglich verwenden, aber sie sind sich dessen einfach nicht bewusst.Hier sind einige sehr einfache Beispiele:ADO.NET, Hibernate/NHibernate, Logging Frameworks, verschiedene Sprachsammlungstypen, der ASP.NET-Stack, der JSP-Stack usw.Dies sind alles Dinge, die in ihren Codebasen stark auf OOP angewiesen sind.

Wiederverwendung sollte kein Ziel von OOP sein – oder auch keinem anderen Paradigma.

Die Wiederverwendung ist ein Nebeneffekt eines guten Designs und eines angemessenen Abstraktionsniveaus.Code erreicht Wiederverwendung, indem er etwas Nützliches tut, aber nicht so viel tut, dass er unflexibel wird.Es spielt keine Rolle, ob der Code OO ist oder nicht – wir verwenden wieder, was funktioniert und was nicht trivial ist, es selbst zu tun.Das ist Pragmatismus.

Der Gedanke, dass OO ein neuer Weg zur Wiederverwendung durch Vererbung ist, ist grundsätzlich fehlerhaft.Wie Sie bemerken, gibt es zahlreiche LSP-Verstöße.Stattdessen wird OO zu Recht als eine Methode zur Bewältigung der Komplexität einer Problemdomäne betrachtet.Das Ziel ist die Wartbarkeit eines Systems im Laufe der Zeit.Das wichtigste Instrument, um dies zu erreichen, ist die Trennung der öffentlichen Schnittstelle von einer privaten Implementierung.Dies ermöglicht es uns, Regeln wie „Dies sollte nur mit ... geändert werden“ vom Compiler durchzusetzen, anstatt den Code zu überprüfen.

Sie werden mir sicher zustimmen, dass wir damit äußerst komplexe Systeme erstellen und warten können.Darin liegt ein großer Wert, und in anderen Paradigmen ist dies nicht einfach.

Das grenzt schon ans Religiöse, aber ich würde sagen, dass Sie ein allzu düsteres Bild vom Zustand des modernen OOP zeichnen.Ich würde behaupten, dass es tatsächlich so ist hat reduzierte Kosten, machte große Softwareprojekte überschaubar und so weiter.Das bedeutet nicht, dass das grundlegende Problem der Software-Unordnung gelöst ist, und es bedeutet auch nicht, dass der durchschnittliche Entwickler ein OOP-Experte ist.Aber die Modularisierung von Funktionen in Objektkomponenten hat sicherlich die Menge an Spaghetti-Code auf der Welt reduziert.

Ich kann mir spontan Dutzende von Bibliotheken vorstellen, die wunderbar wiederverwendbar sind und Zeit und Geld gespart haben, die nie berechnet werden können.

Dass OOP jedoch Zeitverschwendung war, liegt meines Erachtens an der mangelnden Ausbildung der Programmierer und der steilen Lernkurve beim Erlernen einer sprachspezifischen OOP-Zuordnung.Manche Leute „bekommen“ OOP, andere nie.

Ich denke, die Verwendung undurchsichtiger Kontextobjekte (HANDLEs in Win32, FILE*s in C, um nur zwei bekannte Beispiele zu nennen – verdammt, HANDLEs leben auf der anderen Seite der Kernel-Modus-Barriere, und das geht wirklich nicht viel stärker gekapselt) kommt auch im prozeduralen Code vor;Es fällt mir schwer zu erkennen, dass dies etwas Besonderes für OOP ist.

HANDLEs (und der Rest der WinAPI) Ist OOP!C unterstützt OOP nicht sehr gut, daher gibt es keine spezielle Syntax, aber das bedeutet nicht, dass es nicht dieselben Konzepte verwendet.WinAPI ist im wahrsten Sinne des Wortes ein objektorientiertes Framework.

Sehen Sie, das ist das Problem bei jeder einzelnen Diskussion über OOP oder alternative Techniken:Niemand ist sich über die Definition im Klaren, jeder redet über etwas anderes und daher kann kein Konsens erzielt werden.Scheint mir Zeitverschwendung zu sein.

Es ist ein Programmierparadigma.Entwickelt, um es uns Normalsterblichen zu erleichtern, ein Problem in kleinere, umsetzbare Teile zu zerlegen.

Wenn Sie es nicht nützlich finden...Benutzen Sie es nicht, zahlen Sie nicht für die Ausbildung und seien Sie glücklich.

Ich hingegen finde es nützlich, also werde ich es tun :)

Im Vergleich zur reinen prozeduralen Programmierung ist der erste grundlegende Grundsatz von OOP der Gedanke des Versteckens und Kapselns von Informationen.Diese Idee führt zur Vorstellung des Klasse das trennt die Schnittstelle von der Implementierung.Dies sind äußerst wichtige Konzepte und die Grundlage für die Schaffung eines Rahmens, um über Programmdesign anders und besser (meiner Meinung nach) nachzudenken.Gegen diese Eigenschaften kann man nicht wirklich argumentieren – es gibt keinen Kompromiss und es ist immer eine sauberere Art, Dinge zu modulieren.

Andere Aspekte von OOP, einschließlich Vererbung und Polymorphismus, sind ebenfalls wichtig, aber wie andere angedeutet haben, werden diese häufig überbeansprucht.dh:Manchmal verwenden Menschen Vererbung und/oder Polymorphismus, weil sie es können und nicht, weil sie es hätten tun sollen.Es handelt sich um wirkungsvolle und sehr nützliche Konzepte, die jedoch mit Bedacht eingesetzt werden müssen und keine automatischen Vorteile von OOP darstellen.

Im Verhältnis zur Wiederverwendung.Ich stimme zu, dass die Wiederverwendung für OOP übertrieben ist.Dies ist ein möglicher Nebeneffekt gut definierter Objekte, typischerweise primitiverer/allgemeinerer Klassen, und ein direktes Ergebnis der Kapselungs- und Informationsverbergungskonzepte.Die Wiederverwendung ist möglicherweise einfacher, da die Schnittstellen gut definierter Klassen einfach klarer und einigermaßen selbstdokumentierend sind.

Das Problem mit OOP ist, dass es überverkauft war.

Wie Alan Kay es ursprünglich konzipierte, war es eine großartige Alternative zur früheren Praxis, Rohdaten und rein globale Routinen zu verwenden.

Dann griffen einige Unternehmensberatertypen darauf auf und verkauften es als den Messias der Software, und wie ein Lemming folgten ihm Wissenschaft und Industrie hinterher.

Jetzt geraten sie wie ein Lemming ins Straucheln, nachdem andere gute Ideen überverkauft wurden, etwa die funktionale Programmierung.

Was würde ich also anders machen?Genug, und ich habe ein Buch darüber geschrieben.(Es ist vergriffen – ich bekomme keinen Cent, aber Sie können immer noch Kopien bekommen.)Amazonas

Meine konstruktive Antwort besteht darin, Programmierung nicht als eine Möglichkeit zu betrachten, Dinge in der realen Welt zu modellieren, sondern als eine Möglichkeit, Anforderungen zu kodieren.

Das ist etwas ganz anderes und basiert auf Informationstheorie (auf einer Ebene, die jeder verstehen kann).Darin heißt es, dass Programmieren als ein Prozess der Definition von Sprachen betrachtet werden kann und dass die Fähigkeit, dies zu tun, für eine gute Programmierung unerlässlich ist.

Es erweitert das Konzept der domänenspezifischen Sprachen (DSLs).Es stimmt voll und ganz mit DRY überein (wiederholen Sie sich nicht).Es gibt ein großes Lob für die Codegenerierung.Dies führt zu Software mit deutlich weniger Datenstruktur, als es für moderne Anwendungen typisch ist.

Ziel ist es, die Idee wiederzubeleben, dass der Weg nach vorne im Erfindergeist liegt und dass selbst gut akzeptierte Ideen in Frage gestellt werden sollten.

HANDLEs (und der Rest der WinAPI) ist OOP!

Aber sind sie es?Sie sind nicht vererbbar, sie sind schon gar nicht ersetzbar, es fehlen ihnen klar definierte Klassen ...Ich denke, dass sie weit hinter „OOP“ zurückbleiben.

Haben Sie schon einmal ein Fenster mit WinAPI erstellt?Dann sollten Sie wissen, dass Sie eine Klasse definieren (RegisterClass), erstelle eine Instanz davon (CreateWindow), virtuelle Methoden aufrufen (WndProc) und Basisklassenmethoden (DefWindowProc) und so weiter.WinAPI übernimmt sogar die Nomenklatur von SmallTalk OOP und nennt die Methoden „Nachrichten“ (Fensternachrichten).

Handles sind möglicherweise nicht vererbbar, aber es gibt sie final in Java.Es mangelt ihnen nicht an Klasse, sie Sind ein Platzhalter für die Klasse:Das ist es, was das Wort „Griff“ bedeutet.Wenn man sich Architekturen wie MFC oder .NET WinForms ansieht, fällt sofort auf, dass sich bis auf die Syntax nicht viel von der WinAPI unterscheidet.

Ja, OOP hat nicht alle unsere Probleme gelöst, tut mir leid.Wir arbeiten jedoch an einer SOA, die all diese Probleme lösen wird.

OOP eignet sich gut für die Programmierung interner Computerstrukturen wie GUI-„Widgets“, wobei beispielsweise „SelectList“ und „TextBox“ Untertypen von „Item“ sein können, das über gängige Methoden wie „Verschieben“ und „Größe ändern“ verfügt.

Das Problem ist, dass 90 % von uns in der Geschäftswelt arbeiten, in der wir mit Geschäftskonzepten wie Rechnung, Mitarbeiter, Job, Bestellung arbeiten.Diese nicht eignen sich so gut für OOP, weil die „Objekte“ nebulöser sind und Änderungen aufgrund von Geschäftsumgestaltungen usw. unterliegen.

Der schlimmste Fall ist, dass OO enthusiastisch auf Datenbanken angewendet wird, einschließlich der ungeheuren OO-„Verbesserungen“ von SQL-Datenbanken – die zu Recht ignoriert werden, außer von Datenbank-Noobs, die davon ausgehen, dass sie die richtige Vorgehensweise sein müssen, weil sie neuer sind.

Nach meiner Erfahrung bei der Überprüfung von Code und Design von Projekten, die ich durchlaufen habe, ist der Wert von OOP nicht vollständig erkannt, weil viele Entwickler dies getan haben das objektorientierte Modell nicht richtig konzeptualisiert in ihren Gedanken.Daher programmieren sie nicht im OO-Design und schreiben sehr oft weiterhin prozeduralen Code von oben nach unten, was die Klassen hübsch macht Wohnung Design.(falls man das überhaupt „Design“ nennen kann)

Es ist ziemlich beängstigend zu beobachten, wie wenig Kollegen darüber wissen, was eine abstrakte Klasse oder Schnittstelle ist, geschweige denn, wie sie eine Vererbungshierarchie richtig entwerfen, um den Geschäftsanforderungen gerecht zu werden.

Wenn jedoch ein gutes OO-Design vorhanden ist, macht es einfach nur Freude, den Code zu lesen und zu sehen, wie sich der Code auf natürliche Weise in intuitive Komponenten/Klassen einfügt.Ich habe Systemarchitektur und -design immer als das Entwerfen der verschiedenen Abteilungen und Personalstellen in einem Unternehmen wahrgenommen – alle sind dazu da, eine bestimmte Arbeit im Großen und Ganzen zu erledigen und die Synergie hervorzurufen, die erforderlich ist, um die Organisation/das System voranzutreiben.

Das ist natürlich ganz schön selten Leider.Wie das Verhältnis von wunderschön gestalteten zu schrecklich gestalteten physischen Objekten auf der Welt, lässt sich im Großen und Ganzen das Gleiche über Softwareentwicklung und -design sagen.Die Verfügbarkeit guter Werkzeuge führt nicht zwangsläufig zu guten Praktiken und Ergebnissen.

Vielleicht ist eine Haube, ein Schoß oder ein Baum kein Stuhl, aber sie alle sind Isitzbar.

Ich denke, diese Dinge der realen Welt sind Objekte

Du tust?

Welche Methoden gibt es für eine Rechnung?Oh, Moment mal.Es kann sich nicht selbst bezahlen, es kann sich nicht selbst versenden, es kann sich nicht mit den Artikeln vergleichen, die der Lieferant tatsächlich geliefert hat.Es gibt überhaupt keine Methoden;es ist völlig inert und funktionslos.Es handelt sich um einen Datensatztyp (eine Struktur, wenn Sie es vorziehen), nicht um ein Objekt.

Ebenso die anderen Dinge, die Sie erwähnen.

Nur weil etwas real ist, heißt das noch lange nicht, dass es ein Objekt im OO-Sinn des Wortes ist.OO-Objekte sind eine besondere Kopplung von Zustand und Verhalten, die aus eigenem Antrieb agieren kann.Das kommt in der realen Welt nicht häufig vor.

Ich schreibe seit etwa 9 Jahren OO-Code.Abgesehen vom Messaging kann ich mir kaum einen anderen Ansatz vorstellen.Den Hauptvorteil sehe ich völlig im Einklang mit den Aussagen von CodingTheWheel:Modularisierung.OO führt mich natürlich dazu, meine Anwendungen aus modularen Komponenten aufzubauen, die saubere Schnittstellen und klare Verantwortlichkeiten haben (d. h.lose gekoppelter, hochkohärenter Code mit einer klaren Trennung der Belange).

Ich denke, dass OO scheitert, wenn Menschen tief verschachtelte Klassenhierarchien schaffen.Dies kann zu Komplexität führen.Allerdings ist es meiner Meinung nach eine äußerst elegante Sache, die gemeinsame Funktionalität in eine Basisklasse auszuklammern und diese dann in anderen Nachkommenklassen wiederzuverwenden!

Erstens sind die Beobachtungen etwas schlampig.Ich habe keine Zahlen zur Softwareproduktivität und keinen guten Grund zu der Annahme, dass sie nicht steigt.Da es außerdem viele Menschen gibt, die OO missbrauchen, würde eine gute Verwendung von OO nicht unbedingt zu einer Produktivitätssteigerung führen, selbst wenn OO das Beste seit Erdnussbutter wäre.Schließlich ist ein inkompetenter Gehirnchirurg wahrscheinlich schlimmer als gar keiner, aber ein kompetenter kann von unschätzbarem Wert sein.

Abgesehen davon ist OO eine andere Art, Dinge zu ordnen, indem man prozeduralen Code an Daten anhängt, anstatt prozeduralen Code auf Daten anwenden zu lassen.Dies sollte zumindest ein kleiner Gewinn sein, da es Fälle gibt, in denen der OO-Ansatz natürlicher ist.Schließlich hindert niemanden daran, eine prozedurale API in C++ zu schreiben, und die Option, stattdessen Objekte bereitzustellen, macht die Sprache vielseitiger.

Darüber hinaus gibt es etwas, was OO sehr gut macht:Dadurch kann alter Code automatisch und ohne Änderungen neuen Code aufrufen.Wenn ich Code habe, der Dinge prozedural verwaltet, und ich etwas Neues hinzufüge, das einem früheren ähnelt, aber nicht mit diesem identisch ist, muss ich den prozeduralen Code ändern.In einem OO-System erbe ich die Funktionalität, ändere, was mir gefällt, und der neue Code wird aufgrund der Polymorphie automatisch verwendet.Dies erhöht die Lokalität von Änderungen, und das ist eine gute Sache.

Der Nachteil ist, dass gutes OO nicht kostenlos ist:Es erfordert Zeit und Mühe, es richtig zu lernen.Da es ein großes Schlagwort ist, gibt es viele Leute und Produkte, die es schlecht machen, nur um es zu tun.Es ist nicht einfacher, eine gute Klassenschnittstelle zu entwerfen als eine gute prozedurale API, und es gibt alle möglichen Fehler, die leicht gemacht werden können (z. B. tiefe Klassenhierarchien).

Betrachten Sie es als eine andere Art von Werkzeug, das nicht unbedingt allgemein besser ist.Zum Beispiel ein Hammer zusätzlich zu einem Schraubenzieher.Vielleicht werden wir irgendwann aus der Praxis des Software-Engineerings herauskommen, weil wir wissen, mit welchem Schraubenschlüssel wir die Schraube einschlagen müssen.

@Sean

Allerdings ist es meiner Meinung nach eine äußerst elegante Sache, die gemeinsame Funktionalität in eine Basisklasse auszuklammern und diese dann in anderen Nachkommenklassen wiederzuverwenden!

Aber „prozedurale“ Entwickler machen das ohnehin schon seit Jahrzehnten.Die Syntax und Terminologie können unterschiedlich sein, die Wirkung ist jedoch identisch.Hinter OOP steckt mehr als die „Wiederverwendung gemeinsamer Funktionalität in einer Basisklasse“, und ich würde sogar so weit gehen zu sagen, dass man das überhaupt nicht als OOP bezeichnen kann;Das Aufrufen derselben Funktion aus verschiedenen Codeteilen ist eine Technik, die so alt ist wie die Unterprozedur selbst.

@Konrad

OOP mag fehlerhaft sein und sicherlich kein Allheilmittel, aber es macht umfangreiche Anwendungen viel einfacher, weil es eine großartige Möglichkeit ist, Abhängigkeiten zu reduzieren

Das ist das Dogma.Ich sehe nicht, was OOP in dieser Hinsicht wesentlich besser macht als die prozedurale Programmierung früherer Zeiten.Immer wenn ich einen Prozeduraufruf mache, isoliere ich mich von den Besonderheiten der Implementierung.

Für mich liegt in der OOP-Syntax selbst ein großer Wert.Die Verwendung von Objekten, die versuchen, reale Dinge oder Datenstrukturen darzustellen, ist oft viel nützlicher als der Versuch, eine Reihe verschiedener flacher (oder „schwebender“) Funktionen zu verwenden, um dasselbe mit denselben Daten zu tun.Es gibt einen gewissen natürlichen „Fluss“ bei Dingen mit gutem OOP, dessen Lesen, Schreiben und Aufrechterhalten auf lange Sicht einfach sinnvoller ist.

Es spielt keine Rolle, dass eine Rechnung nicht wirklich ein „Objekt“ mit Funktionen ist, die sie selbst ausführen kann – die Objektinstanz kann nur existieren, um Funktionen an den Daten auszuführen, ohne dass man wissen muss, welche Art von Daten tatsächlich vorhanden sind.Die Funktion „invoice.toJson()“ kann erfolgreich aufgerufen werden, ohne dass man wissen muss, um welche Art von Daten es sich bei „invoice“ handelt – das Ergebnis ist JSON, unabhängig davon, ob es aus einer Datenbank, XML, CSV oder sogar einem anderen JSON-Objekt stammt .Bei prozeduralen Funktionen müssen Sie plötzlich mehr über Ihre Daten wissen und erhalten am Ende Funktionen wie „xmlToJson()“, „csvToJson()“, „dbToJson()“ usw.Wenn Sie jemals den zugrunde liegenden Datentyp ändern, wird es irgendwann zu einem völligen Durcheinander und zu RIESIGEN Kopfschmerzen.

Der Sinn von OOP besteht darin, die tatsächliche Implementierung durch Abstrahieren zu verbergen.Um dieses Ziel zu erreichen, müssen Sie eine öffentliche Schnittstelle erstellen.Um Ihnen die Arbeit beim Erstellen dieser öffentlichen Schnittstelle zu erleichtern und die Dinge trocken zu halten, müssen Sie Konzepte wie abstrakte Klassen, Vererbung, Polymorphismus und Entwurfsmuster verwenden.

Für mich besteht das eigentliche übergeordnete Ziel von OOP darin, zukünftige Codewartung und -änderungen einfacher zu machen.Aber auch darüber hinaus kann es die Dinge wirklich erheblich vereinfachen, wenn es richtig gemacht wird, und zwar auf eine Weise, die prozeduraler Code niemals könnte.Es spielt keine Rolle, ob es nicht mit der „realen Welt“ übereinstimmt – das Programmieren mit Code interagiert sowieso nicht mit Objekten der realen Welt.OOP ist einfach ein Tool, das meine Arbeit einfacher und schneller macht – dafür werde ich mich jeden Tag entscheiden.

@CodingTheWheel

Dass OOP jedoch Zeitverschwendung war, liegt meines Erachtens an der mangelnden Ausbildung der Programmierer und der steilen Lernkurve beim Erlernen einer sprachspezifischen OOP-Zuordnung.Manche Leute „bekommen“ OOP, andere nie.

Ich weiß allerdings nicht, ob das wirklich überraschend ist.Ich denke, dass technisch fundierte Ansätze (LSP ist das Offensichtliche) ausreichen schwer zu bedienen, aber wenn wir solche Ansätze nicht verwenden, wird der Code ohnehin spröde und nicht erweiterbar (weil wir nicht mehr darüber nachdenken können).Und ich denke, die kontraintuitiven Ergebnisse, zu denen OOP uns führt, machen es nicht überraschend, dass die Leute es nicht aufgreifen.

Und was noch wichtiger ist: Sollten wir wirklich eine Technik loben, die durchweg schlecht gelehrt wird und schwer zu erlernen scheint, da es für normale Menschen grundsätzlich schon zu schwierig ist, sie zuverlässig und genau zu schreiben?Wenn die Vorteile eindeutig wären, könnte es sich lohnen, trotz der Schwierigkeiten durchzuhalten, aber das scheint nicht der Fall zu sein.

@Jeff

Im Vergleich zur reinen prozeduralen Programmierung ist der erste grundlegende Grundsatz von OOP der Gedanke des Versteckens und Kapselns von Informationen.Diese Idee führt zur Vorstellung der Klasse, die die Schnittstelle von der Implementierung trennt.

Welches hat die verstecktere Implementierung:C++s iostreams oder Cs FILE*s?

Ich denke, die Verwendung undurchsichtiger Kontextobjekte (HANDLEs in Win32, FILE*s in C, um nur zwei bekannte Beispiele zu nennen – verdammt, HANDLEs leben auf der anderen Seite der Kernel-Modus-Barriere, und das geht wirklich nicht viel stärker gekapselt) kommt auch im prozeduralen Code vor;Es fällt mir schwer zu erkennen, dass dies etwas Besonderes für OOP ist.

Ich vermute, dass das einer der Gründe dafür ist, warum es mir schwerfällt, die Vorteile zu erkennen:Die Teile, die offensichtlich gut sind, sind nicht spezifisch für OOP, während die Teile, die spezifisch für OOP sind, nicht offensichtlich gut sind!(Das soll nicht heißen, dass sie unbedingt schlecht sind, sondern vielmehr, dass ich keine Beweise dafür gesehen habe, dass sie allgemein anwendbar und durchweg nützlich sind.)

Im einzigen Entwicklerblog, den ich gelesen habe, von diesem Joel-On-Software-Gründer von SO, ich habe vor langer Zeit gelesen, dass OO nicht zu Produktivitätssteigerungen führt.Die automatische Speicherverwaltung funktioniert.Cool.Wer kann die Daten leugnen?

Ich glaube immer noch, dass OO für Nicht-OO das ist, was das Programmieren mit Funktionen für das Programmieren von allem inline ist.

(Und ich sollte es wissen, da ich mit GWBasic angefangen habe.) Wenn Sie Code umgestalten, um Funktionen zu verwenden, variable2654 wird variable3 der Methode, in der Sie sich befinden.Oder noch besser: Es hat einen Namen, den Sie verstehen können. und wenn die Funktion kurz ist, es heißt value und das reicht zum vollständigen Verständnis.

Wenn Code ohne Funktionen zu Code mit Methoden wird, können Sie kilometerlange Codes löschen.

Wenn Sie Code so umgestalten, dass er wirklich OO ist, b, c, q, Und Z werden this, this, this Und this.Und da ich nicht daran glaube, das zu verwenden this Mit dem Schlüsselwort können Sie kilometerlange Codes löschen.Eigentlich können Sie das sogar tun, wenn Sie es verwenden this.

Ich glaube nicht, dass OO eine natürliche Metapher ist.

Ich denke nicht, dass Sprache auch eine natürliche Metapher ist, und ich denke auch nicht, dass Fowlers "Gerüche" besser sind als "dieser Code schmeckt schlecht". Trotzdem denke ich, dass es bei OO nicht um natürliche Metaphern und Menschen geht, die denken Gegenstände springen einem einfach ins Auge verfehlen im Grunde den Kern. Sie definieren das Objektuniversum, und bessere Objektuniversen führen zu Code, der kürzer, leichter zu verstehen ist, besser funktioniert oder alle diese Kriterien erfüllt (und einige Kriterien vergesse ich).Ich denke, dass Leuten, die die natürlichen Objekte der Kunden/Domäne als Programmierobjekte verwenden, die Macht fehlt, das Universum neu zu definieren.

Wenn Sie beispielsweise ein Flugreservierungssystem betreiben, entspricht das, was Sie eine Reservierung nennen, möglicherweise überhaupt nicht einer rechtlichen/geschäftlichen Reservierung.

Einige der Grundkonzepte sind wirklich coole Tools

Ich denke, dass die meisten Leute mit der ganzen Aussage „Wenn du einen Hammer hast, sind das nur Nägel“ übertreiben.Ich denke, dass die andere Seite der Medaille/des Spiegels genauso wahr ist:Wenn Sie ein Gerät wie Polymorphismus/Vererbung haben, beginnen Sie, Verwendungsmöglichkeiten zu finden, bei denen es wie ein Handschuh/eine Socke/eine Kontaktlinse passt.Die Werkzeuge von OO sind sehr mächtig.Die Einzelvererbung ist meiner Meinung nach absolut notwendig, damit sich die Menschen nicht von mir überwältigen lassen Mehrfachvererbungssoftware nicht standhalten.

Was ist der Sinn von OOP?

Ich denke, es ist eine großartige Möglichkeit, mit einer absolut riesigen Codebasis umzugehen.Ich denke, es ermöglicht Ihnen das Organisieren und Reorganisieren Ihres Codes und stellt Ihnen eine Sprache zur Verfügung, in der Sie dies tun können (über die Programmiersprache hinaus, in der Sie arbeiten), und modularisiert den Code auf eine ziemlich natürliche und leicht verständliche Weise.

OOP wird von der Mehrheit der Entwickler missverstanden

Denn es ist ein augenöffnender Prozess wie das Leben:Mit der Erfahrung verstehst du OO immer besser und fängst an, bestimmte Muster zu meiden und andere zu verwenden, wenn du klüger wirst.Eines der besten Beispiele ist, dass Sie die Vererbung für Klassen, die Sie nicht kontrollieren, nicht mehr verwenden und diese bevorzugen Fassade Muster stattdessen.

Bezüglich Ihres Miniaufsatzes/Ihrer Frage

Ich wollte erwähnen, dass Sie Recht haben.Die Wiederverwendbarkeit ist größtenteils ein Wunschtraum.Hier ist ein Zitat von Anders Hejilsberg zu diesem Thema (brillant) von hier:

Wenn Sie den Beginn der Programmierer bitten, eine Kalenderkontrolle zu schreiben, denken sie oft für sich: "Oh, ich werde die weltbeste Kalenderkontrolle schreiben!Es wird polymorph in Bezug auf den Kalender.Es wird Anzeigen und Mungers und das, das und die andere. "Sie müssen in zwei Monaten einen Kalenderantrag versenden.Sie setzen all diese Infrastruktur in die Kontrolle und verbringen zwei Tage damit, eine beschissene Kalenderanwendung darüber zu schreiben.Sie werden denken: "In der nächsten Version der Anwendung werde ich so viel mehr tun."

Sobald sie darüber nachdenken, wie sie all diese anderen Konkretisierungen ihres abstrakten Designs tatsächlich implementieren werden, stellt sich jedoch heraus, dass ihr Design völlig falsch ist.Und jetzt haben sie sich in eine Ecke gemalt und müssen das Ganze herauswerfen.Das habe ich immer wieder gesehen.Ich bin fest davon überzeugt, minimalistisch zu sein.Wenn Sie das allgemeine Problem nicht lösen, versuchen Sie nicht, einen Rahmen für die Lösung eines bestimmten Lösens eingerichtet zu haben, da Sie nicht wissen, wie dieses Framework aussehen sollte.

Haben Sie schon einmal ein Fenster mit WinAPI erstellt?

Mehr Male, als ich mich erinnern möchte.

Dann sollten Sie wissen, dass Sie eine Klasse definieren (RegisterClass), eine Instanz davon erstellen (CreateWindow), virtuelle Methoden (WndProc) und Basisklassenmethoden (DefWindowProc) aufrufen und so weiter.WinAPI übernimmt sogar die Nomenklatur von SmallTalk OOP und nennt die Methoden „Nachrichten“ (Fensternachrichten).

Dann wissen Sie auch, dass es keinen eigenen Nachrichtenversand durchführt, was eine große Lücke darstellt.Es hat auch beschissene Unterklassen.

Handles sind möglicherweise nicht vererbbar, aber in Java gibt es „final“.Ihnen fehlt keine Klasse, sie sind ein Platzhalter für die Klasse:Das ist es, was das Wort „Griff“ bedeutet.Wenn man sich Architekturen wie MFC oder .NET WinForms ansieht, fällt sofort auf, dass sich bis auf die Syntax nicht viel von der WinAPI unterscheidet.

Sie sind weder in der Schnittstelle noch in der Implementierung vererbbar, nur minimal ersetzbar, und sie unterscheiden sich nicht wesentlich von dem, was prozedurale Programmierer seit jeher tun.

Ist es das wirklich?Die besten Teile von OOP sind einfach...traditionelle Verfahrensordnung? Das ist die große Sache?

Ich stimme voll und ganz zu InSciTek JeffAls Antwort füge ich einfach die folgenden Verfeinerungen hinzu:

Ausblenden und Kapseln von Informationen:Kritisch für jeden wartbaren Code.Kann durch Vorsicht in jeder Programmiersprache durchgeführt werden, erfordert keine OO-Funktionen, aber dadurch wird Ihr Code leicht OO-ähnlich.
Nachlass:Es gibt einen wichtigen Anwendungsbereich, für den all diese OO ist eine Art von Und enthält ein Beziehungen passen perfekt:Grafische Benutzeroberflächen.Wenn Sie versuchen, GUIs ohne OO-Sprachunterstützung zu erstellen, werden Sie am Ende sowieso OO-ähnliche Funktionen erstellen, und ohne Sprachunterstützung ist es schwieriger und fehleranfälliger.Glade (kürzlich) und X11 Xt (historisch) zum Beispiel.

Die Verwendung von OO-Funktionen (insbesondere tief verschachtelter abstrakter Hierarchien) ist sinnlos, wenn es keinen Sinn macht.Aber für einige Anwendungsbereiche gibt es tatsächlich einen Sinn.

Ich glaube, dass die vorteilhafteste Eigenschaft von OOP das Verbergen/Verwalten von Daten ist.Es gibt jedoch VIELE Beispiele, in denen OOP missbraucht wird, und ich denke, hier kommt die Verwirrung ins Spiel.

Nur weil man etwas in ein Objekt verwandeln kann, heißt das nicht, dass man es auch tun sollte.Wenn Ihr Code dadurch jedoch übersichtlicher/leserlicher wird, sollten Sie dies auf jeden Fall tun.

Ein großartiges praktisches Beispiel, bei dem OOP sehr hilfreich ist, ist eine „Produkt“-Klasse und Objekte, die ich auf unserer Website verwende.Da es sich bei jeder Seite um ein Produkt handelt und jedes Produkt Verweise auf andere Produkte enthält, kann es sehr verwirrend sein, auf welches Produkt sich die Daten beziehen, die Sie haben.Ist diese „strURL“-Variable der Link zur aktuellen Seite, zur Startseite oder zur Statistikseite?Natürlich könnten Sie alle möglichen Variablen erstellen, die auf dieselben Informationen verweisen, aber proCurrentPage->strURL ist (für einen Entwickler) viel einfacher zu verstehen.

Darüber hinaus ist das Anhängen von Funktionen an diese Seiten viel sauberer.Ich kann proCurrentPage->CleanCache();Gefolgt von proDisplayItem->RenderPromo();Wenn ich nur diese Funktionen aufrufen und davon ausgehen würde, dass die aktuellen Daten verfügbar sind, wer weiß, was für ein Übel passieren würde.Wenn ich außerdem die richtigen Variablen an diese Funktionen übergeben müsste, stünde ich wieder vor dem Problem, dass alle möglichen Variablen für die verschiedenen Produkte herumliegen.

Stattdessen sind alle meine Produktdaten und -funktionen mithilfe von Objekten übersichtlich und leicht verständlich.

Jedoch.Das große Problem mit OOP besteht darin, dass jemand glaubt, dass ALLES OOP sein sollte.Dadurch entstehen viele Probleme.Ich habe 88 Tabellen in meiner Datenbank.Ich habe nur etwa 6 Klassen und vielleicht sollte ich etwa 10 haben.Ich brauche definitiv keine 88-Klassen.In den meisten Fällen ist der direkte Zugriff auf diese Tabellen unter den Umständen, in denen ich sie verwende, vollkommen verständlich, und OOP würde es tatsächlich schwieriger/mühsamer machen, zur Kernfunktionalität des Geschehens zu gelangen.

Ich glaube, dass ein Hybridmodell aus Objekten, wo nützlich und prozedural, wo praktisch, die effektivste Codierungsmethode ist.Es ist eine Schande, dass wir all diese Religionskriege haben, in denen Menschen dafür plädieren, eine Methode auf Kosten der anderen anzuwenden.Sie sind beide gut und beide haben ihren Platz.Meistens gibt es in jedem größeren Projekt Verwendungsmöglichkeiten für beide Methoden (in einigen kleineren Projekten kann es sein, dass Sie nur ein einzelnes Objekt oder ein paar Prozeduren benötigen).

Die Wiederverwendung ist mir weniger wichtig als die Lesbarkeit.Letzteres bedeutet, dass Ihr Code einfacher zu ändern ist.Das allein ist im Handwerk der Softwareerstellung Gold wert.

Und OO ist eine verdammt effektive Möglichkeit, Ihre Programme lesbar zu machen.Wiederverwendung oder keine Wiederverwendung.

„Die reale Welt ist nicht „OO“,“

Wirklich?Meine Welt ist voller Objekte.Ich benutze jetzt eins.Ich denke, dass es vielleicht gar nicht so schlecht ist, wenn Software-„Objekte“ die realen Objekte modellieren.

OO-Designs für konzeptionelle Dinge (wie Windows, keine realen Fenster, sondern die Anzeigefelder auf meinem Computermonitor) lassen oft zu wünschen übrig.Aber für reale Dinge wie Rechnungen, Versandaufträge, Versicherungsansprüche und was auch immer, ich denke, dass diese realen Dinge Objekte sind.Ich habe einen Stapel auf meinem Schreibtisch, also müssen sie echt sein.

Der Sinn von OOP besteht darin, dem Programmierer eine weitere Möglichkeit zu geben, eine Lösung für ein Problem im Code zu beschreiben und Maschinen und Menschen mitzuteilen.Der wichtigste Teil davon ist die Kommunikation mit den Menschen.OOP ermöglicht es dem Programmierer, durch Regeln, die in der OO-Sprache erzwungen werden, zu deklarieren, was sie im Code bedeuten.

Im Gegensatz zu vielen Argumenten zu diesem Thema sind OOP- und OO-Konzepte im gesamten Code allgegenwärtig, auch im Code in Nicht-OOP-Sprachen wie C.Viele fortgeschrittene Nicht-OO-Programmierer nähern sich den Eigenschaften von Objekten auch in Nicht-OO-Sprachen an.

Durch die Integration von OO in die Sprache erhält der Programmierer lediglich ein weiteres Ausdrucksmittel.

Der größte Teil beim Schreiben von Code ist nicht die Kommunikation mit der Maschine, dieser Teil ist einfach, der größte Teil ist die Kommunikation mit menschlichen Programmierern.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow