Was ist der Sinn von OOP?

Soweit ich das beurteilen kann, hat OOP trotz der unzähligen Millionen oder Milliarden, die für OOP-Schulungen, -Sprachen und -Tools ausgegeben wurden, weder die Entwicklerproduktivität oder die Zuverlässigkeit der Software verbessert noch die Entwicklungskosten gesenkt. Nur wenige Menschen verwenden OOP in einem strengen Sinne (nur wenige Menschen halten sich an Prinzipien wie LSP oder verstehen diese). Die Ansätze zur Modellierung von Problembereichen scheinen wenig einheitlich oder konsistent zu sein. Allzu oft wird die Klasse nur für ihren syntaktischen Zucker verwendet; Dadurch werden die Funktionen für einen Datensatztyp in einen eigenen kleinen Namespace eingefügt.

Ich habe eine große Menge Code für eine Vielzahl von Anwendungen geschrieben. Obwohl es Stellen gab, an denen eine echte ersetzbare Untertypisierung eine wertvolle Rolle in der Anwendung spielte, waren diese ziemlich außergewöhnlich. Obwohl viel Lippenbekenntnis gegeben wird, um von "Wiederverwendung" zu sprechen, ist die Realität, dass es nur sehr wenig kostengünstige "Wiederverwendung" gibt, wenn ein Code nicht genau das tut , was Sie wollen. Es ist äußerst schwierig, Klassen so zu gestalten, dass sie auf die richtige Weise erweiterbar sind. 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 implizierte Idee, dass wir Dinge mit einer Klassentaxonomie modellieren können, scheint mir sehr grundlegend fehlerhaft zu sein (ich kann auf einem Tisch, einem Baumstumpf, einer Motorhaube sitzen , jemandes Schoß - aber keiner von denen ist ein Stuhl). Selbst wenn wir zu abstrakteren Domänen wechseln, ist die OO-Modellierung oft schwierig, nicht intuitiv und letztendlich nicht hilfreich (betrachten Sie die klassischen Beispiele für Kreise / Ellipsen oder Quadrate / Rechtecke).

Was vermisse ich hier? Wo ist der Wert von OOP und warum hat all die Zeit und das Geld es nicht geschafft, Software besser zu machen?

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

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

Es reicht nicht aus, nur OO-Methoden anzuwenden und von Entwicklern die Verwendung solcher Methoden zu verlangen, da dies negative Auswirkungen auf die Entwicklerproduktivität sowie auf die Qualität der entwickelten Systeme haben kann.

Dies stammt aus "Über die Verwendbarkeit von OO-Darstellungen" aus Mitteilungen der ACM vom Oktober 2000. In den Artikeln wird OO hauptsächlich mit dem prozessorientierten Ansatz verglichen. Es gibt viele 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, Band 10, haben ein ganzes Thema über OO-Studien). und nach allem, was ich gelesen habe, gibt es nichts, was auf eine Art Natürlichkeit des OO-Ansatzes hinweist, die ihn besser geeignet macht als einen traditionelleren prozeduralen Ansatz.

Die reale Welt ist nicht "OO", und die in OO implizierte Idee, dass wir Dinge mit einer Klassentaxonomie modellieren können, scheint mir sehr grundlegend fehlerhaft zu sein

Während dies wahr ist und von anderen Leuten beobachtet wurde (nehmen Sie Stepanov, Erfinder der STL), ist der Rest Unsinn. OOP ist möglicherweise fehlerhaft und sicherlich kein Wundermittel, aber es vereinfacht Anwendungen in großem Maßstab erheblich, da es eine hervorragende Möglichkeit ist, Abhängigkeiten zu reduzieren. Dies gilt natürlich nur für „gutes“ OOP-Design. Schlampiges Design bringt keinen Vorteil. Gutes, entkoppeltes Design kann jedoch mit OOP sehr gut und mit anderen Techniken nicht gut modelliert werden.

Es gibt viel bessere, universellere Modelle (man denke an das Modell von Haskell ), aber diese sind oft auch komplizierter und / oder schwierig effizient zu implementieren. OOP ist ein guter Kompromiss zwischen Extremen.

Bei OOP geht es nicht darum, wiederverwendbare Klassen zu erstellen, sondern darum, verwendbare Klassen zu erstellen.

Allzu oft wird die Klasse nur für ihren syntaktischen Zucker verwendet; Dadurch werden die Funktionen für einen Datensatztyp in einen eigenen kleinen Namespace eingefügt.

Ja, ich finde das auch zu weit verbreitet. Dies ist keine objektorientierte Programmierung. Es ist objektbasierte Programmierung und datenzentrierte Programmierung. In meinen 10 Jahren Arbeit mit OO Languages ​​sehe ich Leute, die hauptsächlich objektbasierte Programmierung betreiben. OBP bricht meiner Meinung nach sehr schnell zusammen, da Sie im Wesentlichen das Schlimmste aus beiden Wörtern erhalten: 1) Prozedurale Programmierung ohne Einhaltung der bewährten strukturierten Programmiermethode und 2) OOP ohne Einhaltung der bewährten OOP-Methode.

OOP richtig gemacht ist eine schöne Sache. Es macht es sehr schwierig, sehr schwierige Probleme zu lösen, und für den Uneingeweihten (der dort nicht versucht, pompös zu klingen) kann es fast wie Magie erscheinen. Abgesehen davon ist OOP nur ein Werkzeug in der Toolbox der Programmiermethoden. Es ist nicht die All-End-All-Methodik. Es passt einfach gut zu großen Geschäftsanwendungen.

Die meisten Entwickler, die in OOP-Sprachen arbeiten, verwenden Beispiele für OOP, die direkt in den Frameworks und Typen ausgeführt werden, die sie täglich verwenden, aber sie sind sich dessen einfach nicht bewusst. Hier 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 von OOP abhängen.

Die Wiederverwendung sollte kein Ziel von OOP sein - oder ein anderes Paradigma für diese Angelegenheit.

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

Der Gedanke an OO als neuen Weg zur Wiederverwendung durch Vererbung ist grundlegend fehlerhaft. Wie Sie bemerken, gibt es zahlreiche LSP-Verstöße. Stattdessen wird OO als eine Methode zum Verwalten der Komplexität einer Problemdomäne angesehen. Das Ziel ist die Wartbarkeit eines Systems über einen längeren Zeitraum. Das wichtigste Instrument, um dies zu erreichen, ist die Trennung der öffentlichen Schnittstelle von einer privaten Implementierung. Auf diese Weise können Regeln wie "Dies sollte nur mit ... geändert werden" vom Compiler erzwungen werden, anstatt die Codeüberprüfung durchzuführen.

Ich bin sicher, Sie werden uns damit einverstanden sein, dass wir damit äußerst komplexe Systeme erstellen und warten können. Darin liegt viel Wert, und in anderen Paradigmen ist dies nicht einfach.

Ich bin religiös, aber ich würde sagen, dass Sie ein übermäßig düsteres Bild vom Zustand des modernen OOP zeichnen. Ich würde behaupten , dass es tatsächlich hat Kosten reduziert, machte große Software - Projekte überschaubar, und so weiter. Das bedeutet nicht, dass das grundlegende Problem der Software-Unordnung gelöst ist, und es bedeutet nicht, dass der durchschnittliche Entwickler ein OOP-Experte ist. Aber die Modularisierung der Funktion in Objektkomponenten hat sicherlich die Menge an Spaghetti-Code auf der Welt reduziert.

Ich kann mir Dutzende von Bibliotheken vorstellen, die wunderschön wiederverwendbar sind und Zeit und Geld gespart haben, die niemals berechnet werden können.

In dem Maße, in dem OOP Zeitverschwendung war, würde ich sagen, dass dies auf mangelnde Programmiererausbildung zurückzuführen ist, die durch die steile Lernkurve beim Erlernen eines sprachspezifischen OOP-Mappings noch verstärkt wird. Einige Leute "bekommen" OOP und andere werden es nie.

Ich denke, die Verwendung von undurchsichtigen Kontextobjekten (HANDLEs in Win32, FILE * s in C, um nur zwei bekannte Beispiele zu nennen - Hölle, HANDLEs leben auf der anderen Seite der Kernel-Modus-Barriere, und es wird wirklich nicht viel mehr gekapselt als das) findet sich auch im Verfahrenscode; Ich kämpfe darum zu sehen, wie besonders OOP dies 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 nicht dieselben Konzepte verwendet werden. WinAPI ist im wahrsten Sinne des Wortes ein objektorientiertes Framework.

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

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

Wenn Sie es nicht nützlich finden. Verwenden Sie es nicht, zahlen Sie nicht für das Training und seien Sie glücklich.

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

In Bezug auf die reine prozedurale Programmierung ist der erste grundlegende Grundsatz von OOP der Begriff des Versteckens und Einkapselens von Informationen. Diese Idee führt zu dem Begriff der Klasse , die die Schnittstelle von der Implementierung trennt. Dies sind äußerst wichtige Konzepte und die Grundlage für die Schaffung eines Rahmens, um die Programmgestaltung anders und besser (glaube ich) zu betrachten. Sie können nicht wirklich gegen diese Eigenschaften argumentieren - es wird kein Kompromiss geschlossen und es ist immer eine sauberere Art, Dinge zu modulieren.

Andere Aspekte der OOP, einschließlich Vererbung und Polymorphismus, sind ebenfalls wichtig, aber wie andere angedeutet haben, werden diese häufig überstrapaziert. dh: Manchmal verwenden Menschen Vererbung und / oder Polymorphismus, weil sie es können, nicht weil sie es sollten. Sie sind leistungsstarke Konzepte und sehr nützlich, müssen jedoch mit Bedacht eingesetzt werden und sind keine automatischen Gewinnvorteile von OOP.

Relativ zur Wiederverwendung. Ich bin damit einverstanden, dass die Wiederverwendung für OOP überverkauft ist. Dies ist eine mögliche Nebenwirkung gut definierter Objekte, typischerweise primitiverer / allgemeinerer Klassen, und ist ein direktes Ergebnis der Konzepte der Kapselung und des Versteckens von Informationen. Die Wiederverwendung ist möglicherweise einfacher, da die Schnittstellen gut definierter Klassen einfach klarer und etwas selbstdokumentierender sind.

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

Wie Alan Kay es ursprünglich konzipiert hatte, war es eine großartige Alternative zu der früheren Praxis, Rohdaten und all-globale Routinen zu haben.

Dann klammerten sich einige Typen von Unternehmensberatern daran und verkauften es als Messias der Software, und Lemming-artig, Wissenschaft und Industrie stürzten hinterher.

Jetzt taumeln sie wie Lemminge, nachdem andere gute Ideen überverkauft wurden, wie zum Beispiel die funktionale Programmierung.

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

Meine konstruktive Antwort ist, die Programmierung nicht als eine Möglichkeit zur Modellierung von Dingen in der realen Welt zu betrachten, sondern als eine Möglichkeit, Anforderungen zu kodieren.

Das ist ganz anders und basiert auf der Informationstheorie (auf einer Ebene, die jeder verstehen kann). Es heißt, dass das Programmieren als ein Prozess zum Definieren von Sprachen betrachtet werden kann, und dass die Fähigkeit dazu für eine gute Programmierung wesentlich ist.

Es erhöht das Konzept der domänenspezifischen Sprachen (DSLs). Es stimmt nachdrücklich mit DRY überein (wiederholen Sie sich nicht). Es gibt einen großen Daumen hoch für die Codegenerierung. Dies führt zu Software mit einer massiv geringeren Datenstruktur als es für moderne Anwendungen typisch ist.

Es soll die Idee neu beleben, dass der Weg nach vorne im Erfindungsreichtum liegt und dass auch gut akzeptierte Ideen in Frage gestellt werden sollten.

GRIFFE (und der Rest der WinAPI) ist OOP!

Sind sie es aber? Sie sind nicht vererbbar, sie sind sicherlich nicht ersetzbar, es fehlen genau definierte Klassen ... Ich denke, sie bleiben weit hinter "OOP" zurück.

Haben Sie jemals ein Fenster mit WinAPI erstellt? Dann sollten Sie wissen, dass Sie eine Klasse ( RegisterClass) definieren, eine Instanz davon erstellen ( CreateWindow), virtuelle Methoden ( WndProc) und Methoden der Basisklasse ( ) aufrufen DefWindowProcund so weiter. WinAPI übernimmt sogar die Nomenklatur von SmallTalk OOP und ruft die Methoden "messages" (Window Messages) auf.

Handles sind möglicherweise nicht vererbbar, aber es gibt sie finalin Java. Ihnen fehlt keine Klasse, sie sind ein Platzhalter für die Klasse: Das bedeutet das Wort „Handle“. Bei Architekturen wie MFC oder .NET WinForms ist sofort klar, dass sich außer der Syntax nicht viel von der WinAPI unterscheidet.

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

OOP eignet sich gut zum Programmieren interner Computerstrukturen wie GUI- "Widgets", wobei beispielsweise SelectList und TextBox Untertypen von Item sein können, für die gängige Methoden wie "Verschieben" und "Größenänderung" gelten.

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 zu OOP , weil die „Objekte“ sind nebulös, Änderungen vorbehalten nach Business Reengineering und so weiter.

Der schlimmste Fall ist, wenn OO begeistert auf Datenbanken angewendet wird, einschließlich der ungeheuren OO- "Verbesserungen" an SQL-Datenbanken - die zu Recht ignoriert werden, außer von Datenbank-Noobs, die davon ausgehen, dass sie der richtige Weg sind, um Dinge zu tun, weil sie neuer sind.

Aufgrund meiner Erfahrung mit der Überprüfung von Code und dem Entwurf von Projekten, die ich durchlaufen habe, wird der Wert von OOP nicht vollständig erkannt, da viele Entwickler das objektorientierte Modell in ihren Köpfen nicht richtig konzipiert haben . Daher programmieren sie nicht mit OO-Design und schreiben sehr oft weiterhin Top-Down-Prozedurcode, was die Klassen zu einem ziemlich flachen Design macht. (wenn man das überhaupt "Design" nennen kann)

Es ist ziemlich beängstigend zu beobachten, wie wenig Kollegen wissen, was eine abstrakte Klasse oder Schnittstelle ist, geschweige denn eine Vererbungshierarchie richtig zu entwerfen, die den Geschäftsanforderungen entspricht.

Wenn jedoch ein gutes OO-Design vorhanden ist, ist es einfach eine Freude, den Code zu lesen und zu sehen, wie der Code auf natürliche Weise in intuitive Komponenten / Klassen passt. Ich habe Systemarchitektur und -design immer als das Entwerfen der verschiedenen Abteilungen und Mitarbeiterjobs in einem Unternehmen wahrgenommen - alle sind dazu da, eine bestimmte Arbeit im großen Schema der Dinge zu erledigen und die Synergie zu erzeugen, die erforderlich ist, um die Organisation / das System voranzutreiben.

Das ist natürlich leider ziemlich selten . Wie das Verhältnis von schön gestalteten zu schrecklich gestalteten physischen Objekten auf der Welt kann das Gleiche über Software-Engineering und -Design gesagt werden. Die guten Werkzeuge zur Verfügung zu haben, führt nicht unbedingt zu guten Praktiken und Ergebnissen.

Vielleicht ist eine Motorhaube, ein Schoß oder ein Baum kein Stuhl, aber alle sind ISittable.

Ich denke, diese realen Dinge sind Objekte

Sie machen?

Welche Methoden hat eine Rechnung? Oh, Moment mal. Es kann sich nicht selbst bezahlen, es kann sich nicht selbst senden, es kann sich nicht mit den Artikeln vergleichen, die der Verkäufer tatsächlich geliefert hat. Es gibt überhaupt keine Methoden; Es ist völlig inert und nicht funktionsfähig. Es ist ein Datensatztyp (eine Struktur, wenn Sie es vorziehen), kein Objekt.

Ebenso die anderen Dinge, die Sie erwähnen.

Nur weil etwas real ist, ist es kein Objekt im Sinne von OO. OO-Objekte sind eine eigenartige Kopplung von Zustand und Verhalten, die von selbst handeln kann. Das ist in der realen Welt nicht reichlich vorhanden.

Ich habe in den letzten 9 Jahren oder so OO-Code geschrieben. Abgesehen von der Verwendung von Messaging fällt es mir schwer, mir einen anderen Ansatz vorzustellen. Der Hauptvorteil, den ich sehe, stimmt völlig mit dem überein, was CodingTheWheel gesagt hat: Modularisierung. OO führt mich natürlich dazu, meine Anwendungen aus modularen Komponenten zu konstruieren, die saubere Schnittstellen und klare Verantwortlichkeiten haben (dh lose gekoppelten, hochkohäsiven Code mit einer klaren Trennung der Bedenken).

Ich denke, OO bricht zusammen, wenn Menschen tief verschachtelte Klassenerbschaften schaffen. Dies kann zu Komplexität führen. Es ist jedoch eine zutiefst elegante Sache, IMHO! Eine gemeinsame Funktion in eine Basisklasse zu zerlegen 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 steigen wird. Da es viele Menschen gibt, die OO missbrauchen, würde eine gute Verwendung von OO nicht unbedingt zu einer Produktivitätsverbesserung führen, selbst wenn OO das Beste seit Erdnussbutter wäre. Schließlich ist ein inkompetenter Gehirnchirurg wahrscheinlich schlechter als gar keiner, aber ein kompetenter kann von unschätzbarem Wert sein.

Abgesehen davon ist OO eine andere Art, Dinge anzuordnen, indem prozeduraler Code an Daten angehängt wird, anstatt dass prozeduraler Code Daten verarbeitet. Dies sollte zumindest ein kleiner Gewinn für sich sein, da es Fälle gibt, in denen der OO-Ansatz natürlicher ist. Schließlich hindert nichts jemanden daran, eine prozedurale API in C ++ zu schreiben, und die Option, stattdessen Objekte bereitzustellen, macht die Sprache vielseitiger.

Außerdem macht OO etwas sehr gut: Es ermöglicht dem alten Code, neuen Code automatisch ohne Änderungen aufzurufen. Wenn ich Code habe, der die Dinge prozedural verwaltet, und eine neue Art von Dingen hinzufüge, die ähnlich, aber nicht identisch mit einer früheren 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 von Polymorphismus 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, um es richtig zu lernen. Da es ein wichtiges 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 leicht zu machenden Fehler (wie tiefe Klassenhierarchien).

Betrachten Sie es als eine andere Art von Werkzeug, nicht unbedingt allgemein besser. Zum Beispiel ein Hammer neben einem Schraubenzieher. Vielleicht verlassen wir irgendwann die Praxis des Software-Engineerings, um zu wissen, mit welchem ​​Schraubenschlüssel die Schraube eingeschlagen werden soll.

@ Sean

Es ist jedoch eine zutiefst elegante Sache, IMHO! Eine gemeinsame Funktion in eine Basisklasse zu zerlegen und diese dann in anderen Nachkommenklassen wiederzuverwenden.

Aber "prozedurale" Entwickler machen das sowieso schon seit Jahrzehnten. Die Syntax und Terminologie können unterschiedlich sein, aber der Effekt ist identisch. OOP ist mehr als "die Wiederverwendung allgemeiner Funktionen in einer Basisklasse", und ich könnte sogar so weit gehen zu sagen, dass dies als OOP überhaupt schwer zu beschreiben ist. Das Aufrufen derselben Funktion aus verschiedenen Codebits ist eine Technik, die so alt ist wie die Unterprozedur selbst.

@Konrad

OOP ist möglicherweise fehlerhaft und sicherlich kein Wundermittel, aber es vereinfacht Anwendungen in großem Maßstab erheblich, da es eine hervorragende Möglichkeit ist, Abhängigkeiten zu reduzieren

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

Für mich ist die OOP-Syntax selbst sehr wertvoll. 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" zu Dingen mit gutem OOP, der nur sinnvoller ist, um zu lesen, zu schreiben und langfristig zu pflegen.

Es ist nicht unbedingt wichtig, dass eine Rechnung nicht wirklich ein "Objekt" mit Funktionen ist, die sie selbst ausführen kann. Die Objektinstanz kann nur existieren, um Funktionen für die Daten auszuführen, ohne wissen zu müssen, welcher Datentyp tatsächlich vorhanden ist. Die Funktion "invoice.toJson ()" kann erfolgreich aufgerufen werden, ohne dass Sie wissen müssen, um welche Art von Daten es sich bei "Rechnung" handelt. Das Ergebnis ist Json, unabhängig davon, ob es aus einer Datenbank, XML, CSV oder einem anderen JSON-Objekt stammt . Mit prozeduralen Funktionen müssen Sie plötzlich mehr über Ihre Daten wissen und erhalten Funktionen wie "xmlToJson ()", "csvToJson ()", "dbToJson ()" usw. Es wird schließlich ein komplettes Durcheinander und ein RIESIGE Kopfschmerzen, wenn Sie jemals den zugrunde liegenden Datentyp ändern.

Der Sinn von OOP besteht darin, die tatsächliche Implementierung zu verbergen, indem sie weg abstrahiert wird. Um dieses Ziel zu erreichen, müssen Sie eine öffentliche Schnittstelle erstellen. Um Ihre Arbeit beim Erstellen dieser öffentlichen Schnittstelle zu vereinfachen 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, die zukünftige Wartung und Änderung von Code zu vereinfachen. Aber auch darüber hinaus kann es die Dinge erheblich vereinfachen, wenn es auf eine Weise korrekt ausgeführt wird, 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 nur ein Werkzeug, das meine Arbeit einfacher und schneller macht - das werde ich jeden Tag tun.

@CodingTheWheel

In dem Maße, in dem OOP Zeitverschwendung war, würde ich sagen, dass dies auf mangelnde Programmiererausbildung zurückzuführen ist, die durch die steile Lernkurve beim Erlernen eines sprachspezifischen OOP-Mappings noch verstärkt wird. Einige Leute "bekommen" OOP und andere werden es nie.

Ich weiß nicht, ob das wirklich überraschend ist. Ich denke, dass technisch fundierte Ansätze (LSP ist das Offensichtliche) schwer zu verwenden sind , 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.

Noch wichtiger ist, dass wir, da Software für normale Menschen bereits grundlegend zu schwierig ist, um zuverlässig und genau zu schreiben, wirklich eine Technik preisen sollten, die durchweg schlecht gelehrt wird und schwer zu erlernen scheint? Wenn die Vorteile eindeutig wären, könnte es sich lohnen, trotz der Schwierigkeiten durchzuhalten, aber das scheint nicht der Fall zu sein.

@ Jeff

In Bezug auf die reine prozedurale Programmierung ist der erste grundlegende Grundsatz von OOP der Begriff des Versteckens und Einkapselens von Informationen. Diese Idee führt zu dem Begriff der Klasse, die die Schnittstelle von der Implementierung trennt.

Welches hat die verstecktere Implementierung: C ++ 's Iostreams oder C's FILE * s?

Ich denke, die Verwendung von undurchsichtigen Kontextobjekten (HANDLEs in Win32, FILE * s in C, um nur zwei bekannte Beispiele zu nennen - Hölle, HANDLEs leben auf der anderen Seite der Kernel-Modus-Barriere, und es wird wirklich nicht viel mehr gekapselt als das) findet sich auch im Verfahrenscode; Ich kämpfe darum zu sehen, wie besonders OOP dies ist.

Ich nehme an, das könnte ein Teil dessen sein, warum ich Schwierigkeiten habe, 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! (Dies bedeutet nicht, dass sie notwendigerweise schlecht sind, sondern dass ich nicht die Beweise dafür gesehen habe, dass sie allgemein anwendbar und durchweg nützlich sind).

In dem einzigen Entwickler-Blog, den ich von diesem Joel-On-Software-Gründer von SO gelesen habe, habe ich vor langer Zeit gelesen, dass OO nicht zu Produktivitätssteigerungen führt. Automatische Speicherverwaltung funktioniert. Cool. Wer kann die Daten ablehnen?

Ich glaube immer noch, dass OO für Nicht-OO ist, was Programmieren mit Funktionen bedeutet, alles inline zu programmieren.

(Und ich sollte wissen, wie ich mit GWBasic angefangen habe.) Wenn Sie Code für die Verwendung von Funktionen umgestalten, variable2654wird dies variable3zu 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 für das volle Verständnis.

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

Wenn Sie Code Refactoring wirklich OO, zu sein b, c, qund Zwerden this, this, thisund this. Und da ich nicht daran glaube, das thisSchlüsselwort zu verwenden, können Sie kilometerlangen Code löschen. Eigentlich können Sie das auch tun, wenn Sie es verwenden this.

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

Ich denke auch nicht, dass Sprache eine natürliche Metapher ist, und ich denke auch nicht, dass Fowlers "Gerüche" besser sind, als zu sagen "dieser Code schmeckt schlecht". Trotzdem denke ich, dass es bei OO nicht um natürliche Metaphern geht und dass Leute, die denken, dass die Objekte nur bei Ihnen herausspringen, im Grunde den Punkt verfehlen. Sie definieren das Objektuniversum, und bessere Objektuniversen führen zu Code, der kürzer, leichter zu verstehen, besser funktioniert oder all dies ist (und einige Kriterien, die ich vergesse). Ich denke, dass Menschen, die die natürlichen Objekte der Kunden / Domain als Programmierobjekte verwenden, die Fähigkeit vermissen, das Universum neu zu definieren.

Wenn Sie beispielsweise ein Flugreservierungssystem durchführen, entspricht das, was Sie als Reservierung bezeichnen, möglicherweise überhaupt keiner rechtlichen / geschäftlichen Reservierung.

Einige der Grundkonzepte sind wirklich coole Werkzeuge

Ich denke, dass die meisten Leute mit dieser ganzen Sache "Wenn Sie einen Hammer haben, sind sie alle Nägel" übertreiben. Ich denke, dass die andere Seite der Münze / des Spiegels genauso wahr ist: Wenn Sie ein Gerät wie Polymorphismus / Vererbung haben, finden Sie Verwendungszwecke, bei denen es wie ein Handschuh / eine Socke / eine Kontaktlinse passt. Die Werkzeuge von OO sind sehr mächtig. Einzelvererbung ist meiner Meinung nach absolut notwendig, damit die Leute nicht mitgerissen werden, da meine eigene Mehrfachvererbungssoftware nicht standhält.

Was ist der Sinn von OOP?

Ich denke, es ist eine großartige Möglichkeit, mit einer absolut massiven Codebasis umzugehen. Ich denke, es ermöglicht Ihnen, Ihren Code zu organisieren und neu zu organisieren, und gibt Ihnen eine Sprache, in der Sie dies tun können (über die Programmiersprache hinaus, in der Sie arbeiten), und modularisiert Code auf eine ziemlich natürliche und leicht verständliche Weise.

OOP wird von der Mehrheit der Entwickler missverstanden

Dies liegt daran, dass es ein Prozess ist, der die Augen öffnet wie das Leben: Sie verstehen OO immer mehr mit Erfahrung und beginnen, bestimmte Muster zu vermeiden und andere einzusetzen, wenn Sie klüger werden. Eines der besten Beispiele ist, dass Sie die Vererbung für Klassen, die Sie nicht steuern, nicht mehr verwenden und stattdessen das Fassadenmuster bevorzugen .

In Bezug auf Ihren Mini-Aufsatz / Ihre Frage

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

Wenn Sie Anfänger bitten, ein Kalendersteuerelement zu schreiben, denken sie oft bei sich: "Oh, ich werde das beste Kalendersteuerelement der Welt schreiben! Es wird in Bezug auf die Art des Kalenders polymorph sein. Es wird Anzeigen haben, und Mungers und dies, das und das andere. " Sie müssen eine Kalenderanwendung in zwei Monaten versenden. Sie setzen all diese Infrastruktur in die Steuerung ein und verbringen dann 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 umsetzen werden, stellt sich jedoch heraus, dass ihr Design völlig falsch ist. Und jetzt haben sie sich selbst in eine Ecke gemalt und müssen das Ganze rauswerfen. Ich habe das immer und immer wieder gesehen. Ich glaube fest daran, minimalistisch zu sein. Versuchen Sie nicht, einen Rahmen für die Lösung eines bestimmten Problems einzurichten, es sei denn, Sie lösen das allgemeine Problem tatsächlich, da Sie nicht wissen, wie dieser Rahmen aussehen soll.

Haben Sie jemals ein Fenster mit WinAPI erstellt?

Mehr 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 ruft die Methoden "messages" (Window Messages) auf.

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

Handles sind möglicherweise nicht vererbbar, aber in Java gibt es Finales. Ihnen fehlt keine Klasse, sie sind ein Platzhalter für die Klasse: Das bedeutet das Wort „Handle“. Bei Architekturen wie MFC oder .NET WinForms ist sofort klar, dass sich außer der Syntax nicht viel von der WinAPI unterscheidet.

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

Ist das wirklich so? Die besten Teile von OOP sind nur ... traditioneller Verfahrenscode? Das ist die große Sache?

Ich stimme der Antwort von InSciTek Jeff voll und ganz zu. Ich füge nur die folgenden Verfeinerungen hinzu:

• Verstecken und Einkapseln von Informationen: Entscheidend für wartbaren Code. Dies kann durch Vorsicht in jeder Programmiersprache erreicht werden, erfordert keine OO-Funktionen, aber wenn Sie dies tun, wird Ihr Code leicht OO-ähnlich.
• Vererbung: Es gibt eine wichtige Anwendungsdomäne , für die alle , die OO ist-a-kind-of und enthält-a - Beziehungen sind eine perfekte Passform: Graphical User Interfaces. Wenn Sie versuchen, GUIs ohne OO-Sprachunterstützung zu erstellen, werden Sie ohnehin OO-ähnliche Funktionen erstellen. Ohne Sprachunterstützung ist dies schwieriger und fehleranfälliger. Glade (vor kurzem) und X11 Xt (historisch) zum Beispiel.

Die Verwendung von OO-Funktionen (insbesondere tief verschachtelte abstrakte Hierarchien) ist sinnlos, wenn es keinen Sinn macht. Aber für einige Anwendungsdomänen gibt es wirklich einen Punkt.

Ich glaube, die vorteilhafteste Qualität von OOP ist das Verstecken / Verwalten von Daten. Es gibt jedoch viele Beispiele, bei denen OOP missbraucht wird, und ich denke, hier kommt die Verwirrung ins Spiel.

Nur weil Sie etwas zu einem Objekt machen können, heißt das nicht, dass Sie es sollten. Wenn dies jedoch dazu führt, dass Ihr Code besser organisiert und leichter zu lesen ist, sollten Sie dies auf jeden Fall tun.

Ein großartiges praktisches Beispiel, bei dem OOP sehr hilfreich ist, sind eine "Produkt" -Klasse und Objekte, die ich auf unserer Website verwende. Da jede Seite ein Produkt ist und jedes Produkt Verweise auf andere Produkte enthält, kann es sehr verwirrend werden, auf welches Produkt sich die von Ihnen angegebenen Daten beziehen. Ist diese "strURL" -Variable der Link zur aktuellen Seite, zur Startseite oder zur Statistikseite? Natürlich können Sie alle Arten von 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 () machen; Gefolgt von proDisplayItem-> RenderPromo (); Wenn ich nur diese Funktionen aufgerufen hätte und davon ausgehen würde, dass die aktuellen Daten verfügbar sind, wer weiß, welche Art von Übel auftreten würde. Wenn ich die richtigen Variablen an diese Funktionen übergeben müsste, kehre ich zu dem Problem zurück, dass alle Arten von Variablen für die verschiedenen Produkte herumliegen.

Stattdessen sind alle meine Produktdaten und Funktionen mithilfe von Objekten schön und sauber und leicht zu verstehen.

Jedoch. Das große Problem bei OOP ist, wenn jemand glaubt, dass ALLES OOP sein sollte. Dies schafft viele Probleme. Ich habe 88 Tabellen in meiner Datenbank. Ich habe nur ungefähr 6 Klassen und vielleicht sollte ich ungefähr 10 haben. Ich brauche definitiv keine 88 Klassen. Die meiste Zeit ist der direkte Zugriff auf diese Tabellen unter den Umständen, unter denen ich sie verwende, vollkommen verständlich, und OOP würde es tatsächlich schwieriger / langwieriger machen, zur Kernfunktionalität des Geschehens zu gelangen.

Ich glaube, ein hybrides Modell von Objekten ist nützlich und prozedural, wo praktisch die effektivste Codierungsmethode ist. Es ist eine Schande, dass wir all diese Religionskriege haben, in denen sich die Menschen dafür einsetzen, eine Methode auf Kosten der anderen anzuwenden. Sie sind beide gut und sie haben beide ihren Platz. In den meisten Fällen werden beide Methoden in jedem größeren Projekt verwendet (in einigen kleineren Projekten ist möglicherweise nur ein einzelnes Objekt oder einige Prozeduren erforderlich).

Die Wiederverwendung ist mir weniger wichtig als die Lesbarkeit. Letzteres bedeutet, dass Ihr Code einfacher zu ändern ist. Das allein ist Gold wert, wenn es darum geht, Software zu erstellen.

Und OO ist eine verdammt effektive Methode, um Ihre Programme lesbar zu machen. Wiederverwendung oder keine Wiederverwendung.

"Die reale Welt ist nicht" OO ","

"Ja wirklich?" Meine Welt ist voller Objekte. Ich benutze jetzt eine. Ich denke, dass es keine so schlechte Sache sein kann, wenn Software- "Objekte" die realen Objekte modellieren.

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

Der Zweck von OOP besteht darin, dem Programmierer ein weiteres Mittel zur Beschreibung und Kommunikation einer Lösung für ein Codeproblem an Maschinen und Personen zu geben. Der wichtigste Teil davon ist die Kommunikation mit Menschen. Mit OOP kann der Programmierer anhand von Regeln, die in der OO-Sprache erzwungen werden, deklarieren, was sie im Code bedeuten.

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

Die Integration von OO in die Sprache bietet dem 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.