Modelliert objektorientierte Programmierung wirklich die reale Welt? [geschlossen]

Ich habe gesehen, dass es sich häufig wiederholt. Die objektorientierte Programmierung basiert auf der Modellierung der realen Welt, aber ist es das?

Es scheint mir, dass dies für nichts außerhalb der Geschäftsschicht zutrifft. Meine GUI-Klassen / Datenzugriffsklassen modellieren nichts in der realen Welt. Selbst in meiner Geschäftsebene habe ich Klassen wie Beobachter, Manager, Fabriken usw., die keine Objekte der realen Welt sind. Ich versuche, meine Klassen so zu gestalten, dass sie die Vorteile von Dingen wie der Kapselung nutzen. Ist die reale Welt jedoch verkapselt?

Während einige Objekte, die ich erstelle, Objekte der realen Welt modellieren, würde Pre-OOP-Code nicht dasselbe tun? Ich bezweifle, dass OO als erstes Unternehmen Konzepte wie Customer in seine Codebasis aufgenommen hat. Aber bei OO geht es wirklich darum, wie man Dinge modelliert, und diese Modellierungsmethode scheint mir nicht von der realen Welt inspiriert zu sein.

Also: modelliert objektorientierte Programmierung wirklich die reale Welt?

Nein überhaupt nicht.

Es ist jedoch eine Methode, die es ermöglicht, eine schöne Abstraktion zu erstellen, um komplexe Datenstrukturen zusammen mit einigen Methoden zu speichern, die auf die Datenstrukturen einwirken.

Modelle jeglicher Art modellieren die reale Welt nicht vollständig.

Sie modellieren ausgewählte Teile, die für die jeweilige Anwendung relevant sind.

Sie sprechen von einer Infrastruktur (Beobachter, Manager, Fabriken usw.), die Ihnen dabei hilft, die richtige Abstraktion zu erzielen und die erforderlichen Funktionen wie Persistenz zu unterstützen.

Was ist ein Modell überhaupt?
Ein Modell ist eine vereinfachte Darstellung, mit der die Funktionsweise eines realen Systems oder Ereignisses erklärt wird

Ist die objektorientierte Programmierung ermöglichen Sie die reale Welt zu modellieren?

Definitiv Ja

Es ist fast unmöglich, das System so zu modellieren, dass es genau der realen Welt entspricht.

Muss ich die Software immer genau nach der realen Welt modellieren?

NEIN

Having said , dass Sie alles bedeutet das Modell nicht Sie haben alles zu modellieren. Tatsächlich besteht das Wesentliche einer nützlichen Modellierung darin, eine vereinfachte Darstellung zu präsentieren. Wie viel Vereinfachung ausreicht, um den aktuellen Geschäftsbedarf auszudrücken, und was weggelassen werden muss, ist ein gutes Gleichgewicht zwischen erfolgreichem Einsatz der Technik und dem Verlust der Technik oder dem völligen Verzicht darauf.

Es gibt natürlich Entitäten, die nicht wirklich existieren, aber nur durch die Modellierung können wir sie tatsächlich gut konzeptualisieren.

Ich denke, das Unterrichten, dass es eine Beziehung zwischen Substantiven und Klassen gibt, führt dazu, dass sich lästige schlechte Gewohnheiten entwickeln, die später von einem ungeduldigen Architekten oder leitenden Ingenieur niedergeschlagen werden müssen.

Was gelehrt werden sollte, ist, dass die Klassen abstrakte Objekte modellieren, genau wie es Ihr Gehirn tut. Sie haben ein abstraktes Konzept von "Auto" in Ihrem Kopf, das keinem bestimmten physischen Auto zugeordnet ist. Es ist wiederverwendbar, und spezifische Implementierungen von Auto können davon erben. Ihr Gehirn erstellt sogar Metamodelle für Sie. Sie haben ein mentales Modell dessen, was Denken ist, was ein Konzept ist.

Wenn wir den Leuten beibringen würden, die Modelle zu identifizieren, die sie bereits in Ihrem Kopf generieren, wären sie viel besser vorbereitet, echte Software zu erstellen.

... Die Welt ist reicher als das, was man mit objektorientierter Syntax ausdrücken kann.

Betrachten Sie einige allgemeine Konzepte, mit denen Menschen allgemein alle Systeme verstehen und beschreiben - Konzepte, die nicht in die Form des Objekts passen. Das Vorher / Nachher-Paradigma sowie das von Ursache / Wirkung und der Begriff des Systemzustands gehören zu den anschaulichsten Beispielen. Tatsächlich kann der Vorgang des „Aufbrühens von Kaffee“ oder des „Zusammenbaus eines Fahrzeugs“ oder des „Landens eines Rovers auf dem Mars“ nicht in einfache Objekte zerlegt werden. Ja, sie werden in OO-Sprachen so behandelt, aber das ist erfunden und kontraintuitiv. Die Abfolge der Routine selbst - was kommt unter welchen Bedingungen aufgrund welcher Kausalität vor was - hat in OO einfach keine aussagekräftige Repräsentation , weil OO kein Konzept von Sequenzierung, Zustand oder Ursache hat.

Prozesse sind in der realen Welt und in der Programmierung extrem verbreitet. Im Laufe der Jahre wurden ausgefeilte Mechanismen entwickelt, um Transaktionen, Arbeitsabläufe, Orchestrierung, Threads, Protokolle und andere inhärent "prozedurale" Konzepte zu handhaben. Diese Mechanismen erzeugen Komplexität, da sie versuchen, den inhärenten zeitinvarianten Mangel bei der OO-Programmierung auszugleichen. Stattdessen sollte das Problem an der Wurzel angegangen werden, indem prozessspezifische Konstrukte wie "Vorher / Nachher", "Ursache / Wirkung" und möglicherweise "Systemstatus" als Kernbestandteil der Sprache zugelassen werden.

Zitat Quelle: Victoria Livschitz, The Next Move in Programming

Ja, OO kann oft verwendet werden, um reale Entitäten zu modellieren.

Selbst in meiner Geschäftsebene habe ich Klassen wie Beobachter, Manager, Fabriken usw., die keine Objekte der realen Welt sind.

Verwechseln Sie objektorientierte Entwicklung nicht mit Entwurfsmustern. OO-Analyse und -Design sind ein Mittel, um sich der Programmierung von wartbarem Code zu nähern. In Verbindung mit einer OO-Sprache erhalten Programmierer die Möglichkeit, wiederverwendbaren Code über die Säulen von OO zu erstellen: Kapselung, Polymorphismus und Vererbung.

Um eine Entität zu verkapseln, können wir diese Entität nach ihrem realen Gegenstück modellieren. Wenn wir zum Beispiel eine Gitarre haben, kapselt eine Gitarrenklasse das Verhalten und die Eigenschaften einer echten Gitarre. Wir können die Gitarre weiter abstrahieren, indem wir beispielsweise IInventoryItemdas Potenzial für die Wiederverwendung von Code durch Polymorphismus und Vererbung ausnutzen.

Andererseits stellen wir möglicherweise fest, dass eine Gitarrenfabrik uns bei der Wartung verschiedener Gitarrentypen unterstützen kann. Das liegt nicht an OO. Eine Fabrik ist vielmehr ein Entwurfsmuster, das sich als bewährtes Mittel zur erfolgreichen Erstellung von Wartungscode für einen solchen Zweck bewährt hat. Mit anderen Worten, wir Programmierer lösen oft ähnliche Probleme. Also haben wir eine gemeinsame Lösung gefunden (das Rad nicht neu erfinden).

Das bedeutet nicht, dass OO die reale Welt modellieren muss oder dass dies immer die optimalste Lösung ist. Ganz einfach, dass als Faustregel „OO die reale Welt modellieren“ durchaus Sinn macht.

Es hängt davon ab, von welcher realen Welt Sie sprechen.

Jorge Luis Borges schrieb eine Geschichte "Tlön, Uqbar, Orbis Tertius", in der einer der Bewohner seine reale Welt ganz anders wahrzunehmen scheint:

[...] Die Menschen im imaginären Tlön [...] haben eine extreme Form des berkeleianischen Idealismus und leugnen die Realität der Welt. Ihre Welt wird "nicht als ein Zusammentreffen von Objekten im Raum, sondern als eine heterogene Reihe unabhängiger Akte" verstanden. Einer der imaginären Sprachen von Tlön fehlen Substantive. Seine Zentraleinheiten sind "unpersönliche Verben, die durch einsilbige Suffixe oder Präfixe mit der Kraft von Adverbien gekennzeichnet sind". Borges listet ein tlönisches Äquivalent von "Der Mond stieg über dem Wasser" auf: hlör u fang axaxaxas mlö, was wörtlich "Nach oben hinter dem Onstreaming, das er mondete" bedeutet. [...] In einer anderen Sprache von Tlön ist "die Grundeinheit nicht das Verb, sondern das einsilbige Adjektiv", die in Kombinationen von zwei oder mehr Nomen bilden: "Mond" wird zu "rundem Luftlicht" dunkles "oder"

(kopiert aus dem Wikipedia-Artikel über das Buch)

Für mich geht es nicht so sehr darum, dass die Welt anders wahrgenommen werden kann als wir, was ein bisschen klischeehaft ist, sondern dass die Wahrnehmung der Struktur der Realität selbst von der Sprache abhängt, die wir sprechen, sei es eine natürliche oder eine Programmiersprache. Die Tlönesen mögen mit Lisp sehr zufrieden sein und Java (AKA The Kingdom Of Nouns ) als sehr unnatürlich empfinden , während die meisten terranischen Programmierer eher objektorientierte als funktionale Sprachen bevorzugen. Ich mag beide Stile, da ich denke, dass es hauptsächlich um die Perspektive geht. Einige Probleme lassen sich am besten mit funktionalen, andere mit objektorientierten Programmiertechniken lösen. Ein guter Programmierer betrachtet ein schwieriges Problem immer aus verschiedenen Blickwinkeln, bevor er versucht, eine Lösung zu finden. Oder, wie Alan Kay es ausdrückte: Sicht ist 80 IQ-Punkte wert .

Meine Antwort auf Ihre Frage lautet also: Von welcher realen Welt sprechen Sie? Und wie?

Während einige Objekte, die ich erstelle, Objekte der realen Welt modellieren, würde Pre-OOP-Code nicht dasselbe tun?

Würde ich nicht sagen OOP bindet die Beziehung zwischen Dingen (Eigenschaften / Objekten) und dem, was sie tun können / können (Methoden), wohingegen die prozedurale Programmierung dies nicht tut (abgesehen von bis zu einem gewissen Grad, wenn strenge Typisierung verwendet wird). In einem Modell geht es nicht nur darum, diskrete Teile und Prozesse zu definieren, sondern auch darum, wie sie zusammenpassen. OOP ist dabei besonders gut.

Ich habe gesehen, dass es sich häufig wiederholt. Die objektorientierte Programmierung basiert auf der Modellierung der realen Welt, aber ist es das?

Ja. Die Betonung hier basiert auf . OOP modelliert nicht die reale Welt (wenn ja, dann übrigens) und soll es auch nicht. OOP ermöglicht es uns, Programmierprobleme so zu modellieren, wie wir die reale Welt modellieren: als ein System von Entitäten, die durch unsere Abstraktion ihres Verhaltens definiert werden.

OO-Code modelliert normalerweise nicht die reale Welt - zumindest ist dies nicht das Ziel, es ermöglicht Ihnen lediglich, Ihren Code auf eine natürlichere Weise zu betrachten, als Sie es von der realen Welt her kennen. das ist, was das Zitat zu sagen versucht.

Es modelliert nicht unsere Welt, sondern die menschliche Interpretation unserer Welt. Menschen trennen Dinge auf natürliche Weise als Objekte. OO ist effektiv, weil es Menschen ermöglicht, ihre Denkweise zu programmieren.

OOP ist möglicherweise kein perfektes Modell der realen Welt und der darin enthaltenen Objekte, aber es ist eine Methode, die bei der Bewältigung der zunehmenden Komplexität realer Software hilft. Es hilft auch dabei, Code besser zu schreiben, indem es in logisch verwandte Teile zerlegt wird.

Während ältere prozessorientierte Methoden mit Sicherheit auch Ergebnisse liefern, können Sie mit OOP auch bei großen und komplexen Projekten relativ einfach und schnell dorthin gelangen.

Abstraktion und Verkapselung helfen dabei, sich auf den Kern des Problems zu konzentrieren, und verbergen gleichzeitig alle Installationen, die tatsächlich dazu führen, dass etwas passiert. Vererbung und ermöglicht es Ihnen, eine sinnvolle und logische Beziehung zwischen verschiedenen Aspekten Ihres Codes herzustellen. Polymorphismus fördert die Wiederverwendung von Code und lässt Sie leicht Variationen behandeln (die „ fast gleiche Verhalten wie ein vorhandenes Objekt“ Kategorie von Problemen , die so häufig geschieht) und Code erweitern , indem die einem Objekt zugeordnet Semantik erstreckt.

Ich halte OOP eher für ein bewährtes Hilfsmittel , mit dem Sie alle Komplexitäten eines realen Systems auf effektive Weise bewältigen können. Also, obwohl es kein sehr gründliches Modell der realen Welt ist, ist es nah genug und hilft Ihnen, Dinge zu erledigen, worauf es am Ende IMHO ankommt.

Ich habe gesehen, dass es sich häufig wiederholt. Die objektorientierte Programmierung basiert auf der Modellierung der realen Welt, aber ist es das?

Es scheint mir, dass dies für nichts außerhalb der Geschäftsschicht zutrifft.

Nein. Wie Sie hervorheben, sind viele der in einer OOP-Sprache "modellierten" Dinge abstrakte Konzepte wie Nachrichtenwarteschlangen, Controller und Stacks.

Selbst in Ihrer Geschäftsebene modellieren Sie immer noch nicht "die reale Welt". Angenommen, Sie haben eine Mitarbeiterklasse. Mitarbeiter sind auch Menschen, die auch Säugetiere sind, die auch Tiere sind, die auch ... (gähnt) Mitarbeiter haben Lieblingsfarben, sie tragen bestimmte Kleidung und glauben bestimmte Dinge. Kurz gesagt, es gibt in der realen Welt eine große Bandbreite an Komplexität, die wir in den meisten Programmen nicht einmal erfassen wollen.

Bei der Modellierung konzentrieren wir uns nur auf die Aspekte des Modells, die für die jeweilige Aufgabe von Bedeutung sind. Wenn wir ein Zeiterfassungssystem entwerfen, möchten wir wahrscheinlich eine Art Mitarbeiterklasse, aber diese Klasse benötigt keine Eigenschaft, um die Lieblingsfarbe des Mitarbeiters auszudrücken.

Daher sollten Modelle nicht versuchen (oder so tun), als würden sie die "reale Welt" vollständig abbilden.

Während einige Objekte, die ich erstelle, Objekte der realen Welt modellieren, würde Pre-OOP-Code nicht dasselbe tun? Ich bezweifle, dass OO als erstes Unternehmen Konzepte wie Customer in seine Codebasis aufgenommen hat.

Du hast Recht. Wenn Sie sich große Programme ansehen, die keine OOP-Programme sind, sind sie häufig noch nach Datenstrukturen organisiert. Eine Datenstruktur und alle manipulierenden Funktionen sind aus Gründen der Übersichtlichkeit nahe beieinander definiert. (Das Subversion-Projekt ist ein gutes Beispiel dafür. Datenstrukturen und -funktionen werden mit Modulnamen vorangestellt, damit klar ist, welche Strukturen und Funktionen miteinander verwendet werden sollen.)

Ich bin kein Experte für die Geschichte der Programmiersprachen, aber ich stelle mir vor, dass OOP aus der beiläufigen Beobachtung heraus entstanden ist, dass Code klarer und verständlicher war, wenn er auf diese Weise organisiert wurde strenger durchgesetzt.

Der größte Unterschied zwischen OOP und Nicht-OOP besteht darin, dass OOP Code an Daten bindet. Also anstatt Code wie folgt aufzurufen:

verb(noun);

wir machen das stattdessen:

noun->verb();

Obwohl dies wie ein grammatikalischer Unterschied erscheint, ist der Unterschied tatsächlich in der Denkweise. Wir sagen Objekten, was zu tun ist, und normalerweise ist es egal, wie der interne Zustand oder die Funktionsweise des Objekts sind. Wenn wir ein Objekt beschreiben, müssen wir nur die öffentliche Schnittstelle beschreiben, um damit arbeiten zu können.

Modelliert objektorientierte Programmierung wirklich die reale Welt?

Nicht vollständig.

Nun, in der realen Welt stehen wir vor echten Problemen. Wir möchten dieses Problem mit einem Paradigma lösen, das das System nachbildet, das wir bauen möchten und das zum Modell wird.

Wenn zum Beispiel eine Warenkorbanwendung das Problem war, haben wir verschiedene Entitäten wie

1. Produkt, das ein abstrakter Begriff ist, der mehrere Mitglieder haben kann, wie Bücher, Gadgets, Autos, die wiederum unterteilt werden können.

2. Steuerkriterien wie (Umsatzsteuer) hängen davon ab, an welchem ​​Standort die Software implementiert wird, da sie aufgrund staatlicher Richtlinien Änderungen unterliegt.

3. Die Steuer hängt davon ab, ob das Produkt zusammen mit Steuerkriterien eingeführt wurde.

4. Der Benutzer könnte einen Einkaufswagen haben, der eine Liste von Produkten usw. enthält.

Wie Sie sehen, gibt es echte Probleme, die wir zu lösen versuchen, die jedoch gemäß dem OOP-Paradigma modularisiert wurden, um sie so nah wie möglich an das reale System heranzuführen.

Ich denke, Sie lesen zu viel in einer sehr prosaischen, historischen Aussage. Viele der Ideen zu OO-Programmierung, Klassen, Polymorpismus, virtuellen Funktionen usw. wurden bereits in den 1960er Jahren in der Sprache Simula eingeführt (http://en.wikipedia.org/wiki/Simula). Wie der Name schon sagt, wurde Simula als Sprache für das Schreiben von Simulationen entwickelt. In der Vergangenheit wurden also OO-Ideen eingeführt, um die "reale Welt" zu modellieren. Ob sie mehr Erfolg haben als andere Stile, ist umstritten.

Während einige Objekte, die ich erstelle, Objekte der realen Welt modellieren, würde Pre-OOP-Code nicht dasselbe tun?

Der größte Unterschied zwischen OOP- und Pre-OOP-Code besteht darin, dass ersterer eine reale Situation als eine Gruppe unterschiedlicher Entitäten modelliert, die miteinander interagieren, wobei jede über eine begrenzte "Macht" verfügt, was sie kann, und auch in der Lage ist, darauf zu "reagieren" externe Ereignisse mit eigenen Aktionen. Letzteres modelliert alles als einen großen Datenblock, der nichts für sich tut, während die Berechnung "Dinge darstellt, die passieren" und einige oder alle von ihnen beeinflussen kann.

Ob es die reale Welt besser modelliert oder nicht, hängt wirklich davon ab, welche Facetten der Welt Sie modellieren. Eine physikalische Simulation, bei der Sie beispielsweise die Auswirkungen beschreiben möchten, die ein angezündetes Feuer auf die umgebenden Objekte haben würde, würde besser durch einen "traditionellen" Ansatz dargestellt werden, da sowohl Licht als auch Wärme gut sind. Definierte Prozesse, die sich sowohl auf den externen als auch auf den internen Zustand anderer Objekte auswirken und sich nicht nach dem Verhalten der einzelnen Objekte richten, sondern nur von deren Eigenschaften abhängen.

Wenn Sie andererseits verschiedene Komponenten modellieren, die interagieren, um das gewünschte Verhalten zu erzielen, kann es einfacher sein, sie als Agenten anstelle von passiven Dingen zu behandeln, ohne etwas zu verpassen. Wenn ich meinen Fernseher einschalten möchte, drücke ich einfach die Taste. Wenn das Netzkabel abgezogen ist, TV.turnOnwird dies für mich überprüft. Es besteht also kein Risiko, ein Zahnrad zu drehen und zu vergessen, das andere zu drehen, das es berührt, da sich das Zahnrad selbst (wenn es richtig programmiert ist) um die sekundären Wechselwirkungen kümmert, die sich aus dem primären ergeben.

Aber bei OO geht es wirklich darum, wie man Dinge modelliert, und diese Modellierungsmethode scheint mir nicht von der realen Welt inspiriert zu sein.

Ich glaube, es hat mehr damit zu tun, wie wir die Welt wahrnehmen, als wie die Welt tatsächlich ist. Man könnte argumentieren, dass alles nur eine Ansammlung von Atomen (oder Energie oder Wellen, was auch immer) ist, aber das hilft uns nicht bei der Bewältigung der Probleme, mit denen wir konfrontiert sind, indem wir die Umwelt um uns herum verstehen und zukünftige Ereignisse vorhersagen ( oder frühere beschreiben). Wir machen also "mentale Modelle" der Welt, und oft finden diese mentalen Modelle eine bessere Übereinstimmung mit OO als die data + process-Modelle - die wohl "besser" modellieren, wie die reale Welt tatsächlich funktioniert.

Es ist auch interessant festzustellen, dass die meisten Leute OOP als Synonym für "klassisches OOP" ansehen, bei dem wir taxonomisch Mengen und Teilmengen von Dingen erstellen und Objekte eindeutig in eine ganz bestimmte Menge einordnen. Dies ist sehr nützlich, um wiederverwendbare neue Typen zu erstellen , aber nicht so gut, wenn die zu modellierende Entität ziemlich eigenständig ist und wenn sie Interaktionen mit anderen Objekten initiiert, ist sie selten, wenn überhaupt, das Ziel einer Interaktion. Oder schlimmer, wenn es nur wenige (vielleicht nur eine) Instanzen dieser Entität gibt oder die Instanzen in ihrer Zusammensetzung, ihrem Verhalten oder in beidem stark variieren.

Es gibt jedoch auch ein "prototypisches OOP", bei dem ein Objekt beschrieben wird, indem ein ähnliches ausgewählt und die Aspekte aufgezählt werden, bei denen sie sich unterscheiden. Ich würde diesen Aufsatz für eine gute und nicht allzu technische Erklärung des Denkprozesses vorschlagen (der ganze Beitrag ist zu groß, selbst für Steve Yegges Standards, also verweise ich auf den relevanten Abschnitt: P). Auch dies ist eine gute Übereinstimmung mit unseren mentalen Modellen, wenn wir uns unbekannte Instanzen im Vergleich zu einer bekannten vorstellen, aber nicht unbedingt, wie die reale Welt "funktioniert" ... (zwei Kühe sind tatsächlich völlig voneinander getrennte Einheiten, auch wenn wir sie wahrnehmen in vielerlei Hinsicht "gleich" sein)

Ich denke, "Does" ist der wichtige Teil dieser Frage. Ich denke , die objektorientierte Programmierung mit Sicherheit Kann reale Welt „Objekte“ modellieren, aber dies ist die Programmierung . Es gibt keine Methodik, die nicht missbraucht werden kann, daher halte ich es nicht für fair, zu sagen, "OOP modelliert nicht die reale Welt", nur weil man mit Objekten dumme Dinge machen kann. Das ist nicht fairer als zu sagen, dass Zeiger nicht sicher sind, weil man mit Zeigern dumme Sachen machen kann.

Der Wikipedia-Artikel zu diesem Thema bringt es auf den Punkt:

Modellierung und Beziehungen
in der realen Welt OOP kann verwendet werden, um reale Objekte und Prozesse mit digitalen Gegenstücken zu verknüpfen. Allerdings sind sich nicht alle einig, dass OOP direktes Mapping in der realen Welt ermöglicht (siehe Abschnitt Negative Kritik) oder dass Mapping in der realen Welt sogar ein würdiges Ziel ist. Bertrand Meyer argumentiert in Object-Oriented Software Construction [21], dass ein Programm kein Modell der Welt ist, sondern ein Modell eines Teils der Welt; "Die Realität ist ein Cousin zweimal entfernt".

Die Sache ist, wenn Ihr Programm keine Universumsimulation ist, kümmern Sie sich nur um Teile der realen Welt - daher "Modell". Dafür gibt es Modelle, die Ihnen die Struktur und Funktionalität geben, die Sie anzeigen müssen.

In der realen Welt haben wir Dinge (Objekte) und Dinge können Aktionen (Methoden) ausführen. Wir können Aspekte von Dingen quantifizieren (Eigenschaften). OOP hat das Potenzial, Dinge der realen Welt zu modellieren, wenn sie reduktionistisch eingesetzt werden. Jedes komplexe Ding hat kleinere oder spezifischere Unterklassen und all diese Dinge haben natürliche Wechselwirkungen über Methoden.

OOP ist eine Abstraktionsmethode. Das Praktische ist also, ob OOP Objekte in der realen Welt wirklich logisch modelliert. Es ist weniger wichtig, dass Sie nicht jede einzelne mögliche Sache modellieren , die alles jemals tun könnte . Wenn Sie alles Mögliche tun müssen, modellieren Sie nicht wirklich .

Um über die Objektorientierung im richtigen Kontext nachzudenken, gehen wir eine Abstraktionsebene höher und sprechen über das Programmieren im Allgemeinen.

Unabhängig davon, ob Sie OO oder funktionale Ansätze verfolgen, muss Ihr Programm etwas tun , nicht wahr? Der springende Punkt des Programms ist es, bestimmte Verhaltensweisen mit bestimmten Reizen zu zeigen. Die Gründe, warum Programme überhaupt existieren, sind, dass sie etwas tun . Das Schlüsselwort hier ist Verhalten .

Zusätzlich zu der Überlegung, welche Verhaltensweisen ein Programm implementieren muss, muss Ihr Programm im Allgemeinen bestimmte Eigenschaften aufweisen. Beispielsweise reicht es nicht aus, dass ein Herzmonitor-Programm das erforderliche Verhalten aufweist - es muss in der Regel auch schnell genug ausgeführt werden, um nahezu in Echtzeit zu arbeiten. Andere "Eigenschaften", die ein Programm aufweisen muss, sind: Sicherheit, Flexibilität, Modularität, Erweiterbarkeit, Lesbarkeit usw. Wir nennen diese Architekturqualitätsattribute . Wir können also sagen, dass unser Programm bestimmte (funktionale) Verhaltensziele erfüllen und bestimmte (nicht funktionale) Eigenschaften aufweisen muss.

Bisher hat nichts davon über OO gesprochen, oder? Machen wir das jetzt.

Sobald ein Ingenieur die Anforderungen (Verhalten, AQAs, Einschränkungen usw.) verstanden hat, stellt sich die Frage: Wie soll ich meinen Code so organisieren, dass er alle erforderlichen Aufgaben ausführt und gleichzeitig die Eigenschaften aufweist, die für ein nützliches Programm erforderlich sind? Objektorientierte Programmierung ist eine Strategie zum Organisieren der Programmfunktionalität in zusammenhängenden Modulen von zusammenwirkenden Objekten. Funktionale Programmierung ist nur eine weitere Strategie, um die Funktionalität Ihres Programms zu organisieren, und dies auf eine andere Art und Weise. Beide Strategien haben ihre Stärken und Schwächen.

Wir haben kürzlich ein Wiederaufleben von Funktionskonzepten erlebt, weil es Stärken aufweist, die unter anderem für eine stark verteilte Verarbeitung sehr überzeugend sind.

Wenn Sie jedoch zu OO zurückkehren, können Sie jetzt sehen, dass es nicht unbedingt die "reale Welt" modelliert. Es organisiert das Verhalten Ihres Programms so, dass Ihr Programm die Eigenschaften aufweist, die zur Erreichung einer beliebigen Anzahl von Geschäftszielen erforderlich sind. Techniken wie TDD, DDD und BDD sind die Methoden, mit denen wir herausfinden, wie wir unsere Objekte am besten organisieren können. Bücher wie Principles, Patterns und Practices , Grow Object Oriented Software Guided by Tests , Specification by Example und Domain Driven Design beschreiben Theorie und Praxis der Objektorientierung mit dem Schwerpunkt auf verhaltensorientiertem Design.

Wenn Sie über Dinge wie "Beobachter, Manager, Fabriken usw." lesen, wenden Sie OO-Muster an, mit deren Hilfe Ihr Programm bestimmte Eigenschaften aufweist, die möglicherweise erforderlich sind, damit es nützlich ist. Dies sind "bewährte Rezepte", die "eher funktionieren", vorausgesetzt, Ihre Anforderungen stimmen mit dem Problem überein, das das Muster löst.

Ich hoffe, das hilft Ihnen zu verstehen, worum es bei OO geht, ohne zu voreingenommen zwischen OO und funktionalen Paradigmen zu wirken.

Aus Sicht der Programmierung erstellt OOP ein schönes Modell, das die reale Welt nicht widerspiegelt.

Es gibt jedoch viel bessere Annäherungen an die reale Welt, die unter dem Begriff domänenspezifische Sprachen ( DSL ) bekannt sind. Boo bietet Ihnen beispielsweise die Möglichkeit, lesbaren Code in nahezu einfachem Englisch zu schreiben (Beispiel aus dem Artikel ).

apply_discount_of 5.percent:
         when order.Total > 1000 and customer.IsPreferred
         when order.Total > 10000

suggest_registered_to_preferred:
         when order.Total  > 100 and not customer.IsPreferred

Ein weiteres Beispiel wären automatisierte Frameworks für Benutzerakzeptanztests, die auf der Sprache von Gherkin basieren .

Feature: Some terse yet descriptive text of what is desired
    In order to realize a named business value
    As an explicit system actor
    I want to gain some beneficial outcome which furthers the goal

Scenario: Some determinable business situation
    Given some precondition
        And some other precondition
    When some action by the actor
        And some other action
        And yet another action
    Then some testable outcome is achieved
        And something else we can check happens too

Es liegt an dir, endlich. OOP ist jedoch ein präziser Weg als andere Methoden wie strukturierte oder prozedurale Programmierung. Der prozedurale Takt könnte möglicherweise Ihre Probleme lösen, aber durch Befolgen von OOP können Sie das Leben leichter machen.