Wie kann man einer nicht technischen Person OOP-Konzepte erklären?

Ich versuche oft zu vermeiden, Leuten zu sagen, dass ich Programmierer bin, weil ich ihnen die meiste Zeit erkläre, was das wirklich bedeutet. Wenn ich ihnen sage, dass ich in Java programmiere, stellen sie häufig allgemeine Fragen zur Sprache und zu den Unterschieden zwischen x und y. Ich bin auch nicht gut darin, Dinge zu erklären, weil 1) ich nicht so viel Erfahrung auf dem Gebiet habe und 2) ich es wirklich hasse, nicht-technischen Leuten Dinge zu erklären.

Sie sagen, dass Sie die Dinge wirklich verstehen, wenn Sie sie jemand anderem erklären. Wie würden Sie in diesem Fall einer nicht technischen Person die OOP-Terminologie und -Konzepte erklären?

Im Allgemeinen versuche ich, die objektorientierte Programmierung anhand von Beispielen aus der Praxis zu beschreiben.

Zum Beispiel könnte ich sagen, dass eine aufgerufene Klasse Vehicledie minimalen Dinge beschreibt, die ein Fahrzeug ist. Ich werde die Person bitten, mir zu sagen, was sie für ein Fahrzeug hält. Manchmal sagen sie Dinge wie "Nun, wie ein Auto oder ein Lastwagen", und ich nicke und stimme ihnen zu. Dann werde ich fragen, was die Unterschiede zwischen einem Auto und einem LKW sind. Manchmal erwähnen sie Größe, manchmal den Zweck und andere Dinge.

Dann werde ich sie bitten, ein Auto oder einen LKW zu vergessen und sie bitten, weiterhin ein Fahrzeug zu beschreiben:

"Oh, gut, es bewegt sich"

"Es hat einen Bediener oder einen Fahrer"

usw...

Bald wissen wir, was ein Fahrzeug ist, und ich sagte, dass wir in OOP ein Fahrzeug definieren würden und aus Gründen der Argumentation sagen würden, dass es sich bewegen kann, und ihm eine Art Fahrer geben würden. Dann werde ich fragen, ok, was hat ein Auto?

"Türen"

"Windows"

Und dann ein LKW ....

"Türen" "Fenster" "Mehr Räder!"

Bald nach vielen Diskussionen hat die andere Person im Allgemeinen Folgendes identifiziert:

1) Was macht ein Fahrzeug aus?

2) Was macht ein Auto aus?

3) Was macht einen LKW aus?

4) Was macht ein Flugzeug aus?

Alles ohne technische Details. Wir haben die Eigenschaften der einzelnen Bereiche in die richtigen Bereiche unterteilt. Sie verstehen Vererbung ("Ja, ein Auto ist ein Fahrzeug, ein LKW ist ein Fahrzeug, aber ein Auto ist kein LKW, es ist EINFACH, duh!").

Sie verstehen sogar Polymorphismus: "Sicher, sie machen im Grunde das Gleiche, aber das könnte es etwas anders machen." Wir können über Verhalten sprechen und wo das in unserem Objektbaum leben soll.

Abhängig von ihrer Ausbildung und ihrem Hintergrund erhalten einige es schneller als andere. Aber wenn ich OOP mit realen Objekten vergleiche, bekommen die meisten Leute es immer. Tatsächlich habe ich in Gesprächen mit nicht-technischen Leuten Dinge gefunden, an die ich nie gedacht hatte. Fahrzeuge müssen zum Beispiel nicht besetzt sein (Drohnen), aber hätte ein Programmierer den Betreiber des Fahrzeugs als eine Eigenschaft davon angesehen? Ich sage nicht, dass es richtig oder falsch ist, einen Operator erwähnen zu lassen, aber es lässt uns darüber nachdenken, was wir modellieren und was wir erreichen wollen, wenn wir Software entwickeln.

Nun, teilweise Template-Spezialisierung, andererseits .... :)

Objekte sind Substantive, Methoden sind Verben.

Hier ist eine Version meiner eingemachten Antwort, die ich der ultra-nicht-technischen Person gebe:

Das Programmieren ist ein Versuch, eine Darstellung der Realität auf dem Computer zu erstellen. Es gibt bereits viele Tools und Geräte, die dies tun. Überlegen Sie, wie eine Tabelle die Darstellung von Buchhaltung oder Statistik erleichtert oder wie eine Powerpoint-Präsentation das Speichern und Anzeigen unserer Präsentationen ermöglicht.

Manchmal müssen wir benutzerdefinierte Darstellungen der Realität in neue oder vorhandene Anwendungen einbauen, die unsere Geschäftsprozesse widerspiegeln. Es gibt viele Möglichkeiten zum Programmieren, und eine der häufigsten Möglichkeiten zum Programmieren ist die objektorientierte Programmierung, bei der der von uns erstellte Code speziell darauf ausgelegt ist, die Konzepte der Realität zu replizieren. Die "Dinge" in Wirklichkeit haben Attribute und Verhaltensweisen. Zum Beispiel hat ein Mensch oft Arme und Beine, Haarfarbe, ethnische Zugehörigkeit und kann oft sprechen und gehen.

Sprechen und Gehen kann in verschiedenen Varianten erfolgen, z. B. welche Sprache man spricht oder wie schnell oder wie man geht.

Menschen haben oft Interaktionen mit anderen Arten von "Dingen", sei es Tiere, andere Menschen, andere lebende Organismen oder leblose Objekte. In der Realität gibt es Themen, die häufig dargestellt werden müssen, z. B. Interaktionen zwischen "Dingen", Kategorisierung von Dingen usw. Berücksichtigen Sie Geschäftsprozesse, die in unserer Organisation ablaufen. Es gibt eine sehr komplizierte "Geschäftslogik", die in der von unserer Organisation verwendeten Software dargestellt werden muss.

Die objektorientierte Programmierung bietet die Möglichkeit, diese "realen Konzepte" und "Geschäftslogik" genau darzustellen.

-> Diese Aussage reicht normalerweise aus, um ihre Neugier abzuwehren (oder sie vielleicht zu Tränen zu langweilen), aber wenn sie mehr Fragen haben, legt die obige Aussage (glaube ich) eine anständige Grundlage dafür, wohin das Gespräch führen kann. Ich denke nicht wirklich, dass sich die nicht-technische Person zu sehr mit technischen Begriffen wie "Abstraktion", "Zusammensetzung", "Polymorphismus" usw. befasst, aber wenn ja, erlaubt mir die Sprache, die ich in der vordefinierten Aussage verwendet habe darauf basierende Beispiele zu ziehen.

Ich habe OOP immer so gelernt:

Sie haben eine Uhr und sie zeigt die Zeit an - nun, beim Programmieren setzen Sie den gesamten Code und die Dinge, die Sie tun müssen, zusammen (klingt ziemlich offensichtlich, aber die Leute haben dies früher nicht so gemacht). Wie auch immer, das nennt man Kapselung .

Jetzt haben Sie eine Uhrensache, vielleicht möchten Sie einen Wecker - nun, wenn Sie alle Dinge zusammen haben, können Sie Dinge hinzufügen, um mehr zu tun - wie den Wecker stellen und ihn klingeln lassen. Dies nennt man Vererbung .

Sie sehen auch auf die Uhr, die ich am Handgelenk habe, aber Sie können auch andere Uhren verwenden, die anders aussehen wie eine Standuhr oder eine Digitaluhr. Es sieht anders aus, aber es ist immer noch eine Uhr - das nennt man Polymorphismus .

Und da haben Sie die 3 Ecken der objektorientierten Programmierung. Der Rest ist nur Codierung.

Ich würde ihnen nur sagen, dass sie sich für einen Kurs in OOP anmelden sollen, wenn sie es wirklich verstehen wollen.

Ich meine, all diese Analogien wie Car.startEngine (); sind, seien wir ehrlich - purer Rap. Als ich vor vielen Jahren zum ersten Mal bei OOP war, stellte ich fest, dass diese die Domäne nur noch weiter abstrahieren.

Anstatt nur zu erklären, dass es bei OOP darum geht, die Komplexität von prozeduralen Sprachen zu verwalten, gehen fast 80% der Programmierbuchautoren davon aus, dass Programmierer ahnungslose Idioten sind, die in einfachen Worten gesprochen werden müssen (siehe die Ironie hier?).

Ja, es ist völlig normal, Listen und Vektoren zu erklären, denn damit arbeiten wir hauptsächlich, nicht mit Car.Engine und PoliceMan.Arrest (es sei denn, Sie sind ein Spieleentwickler, aber andererseits müssen Sie immer noch Ihren Anteil an den gehabt haben ehemalige).

Zurück zum Thema, ich würde ihnen nur sagen, ich erstelle immaterielle Objekte, die nur im Kopf des Programmierers existieren, zum Zweck der Lohnabrechnung / des Spielens / der Space-Shuttle-Navigation usw.

Wenn sie noch Fragen haben, hören Sie auf zu diskutieren, weil es sich nicht lohnt. Die meisten Menschen können sich keine abstrakten Begriffe vorstellen und brauchen Beispiele für fast alles (was wirklich eine stärkere Vereinfachung / Spezialisierung des eigentlichen Themas bedeutet).

Ich habe über ein Gespräch mit meiner Frau über genau diese Sache gesprochen, in dieser Antwort hier: /software/45464/how-to-convince-non-programmer-his-notions-about- Computer sind falsch / 45467 # 45467

EDIT: Die Frage, die ich dort beantwortet habe, wurde moderiert, daher werde ich meine Antwort hier wiederholen.

Sie saß mit meiner Frau in einem Restaurant und fragte mich: "Was bedeutet objektorientiert?"

Ich fing an, über die Wiederverwendung und Kapselung von Code und Polymorphismus nachzudenken, und irgendwann stellte ich fest, dass ihre Augen endlos glasig waren.

Also nahm ich ein Splenda-Päckchen aus dem Container. Ich sagte: "Hier ist ein Objekt. Was sind seine Eigenschaften?"

Sie sagte: "Es ist rechteckig, es besteht aus Papier, es enthält Splenda, es ist blau, es ist bedruckt."

Ich nahm ein Zuckerbeutel. "Was hat es mit diesem gemeinsam?"

Sie sagte: "Die Rechteckigkeit, das Papier, das dort gedruckt wird."

Ich sagte: "Was ist damit, dass beide etwas Süßes enthalten?"

Sie sagte: "Sicher."

Ich sagte: "Das sind also beide Beispiele für das, was wir als abstraktes Süßstoffpaket bezeichnen könnten. Ein platonisches ideales Süßstoffpaket, wenn Sie möchten."

Sie sagte: "Sicher."

Ich sagte: "Und jeder hat Eigenschaften, die vom abstrakten Paket geerbt wurden, und dann Variationen davon, die spezifisch für seine Art von Dingen sind."

Sie sagte: "Richtig. Oh! Und wenn ich ein Saccharine-Paket machen wollte, würde ich das generische nehmen und die Details für das Saccharine festlegen, und dann hätte ich das!"

Ich sagte: "Bingo: Objektorientierte Programmierung."

Sie und ich wissen, dass sie sich gerade den Weg zum Factory-Designmuster erahnt hat. Was auch immer. Es zeigt Vererbung, Kapselung, Objektklassenidentität ... Gutes Zeug.

Diese Frage scheint dennoch ein Kandidat für die Schließung zu sein ...

Wie die meisten Dinge ist OOP auf konzeptioneller Ebene sehr einfach zu erklären. Programmierer modellieren Objekte; und:

• Objekte haben Status (Felder / Datenelemente)
• Objekte haben Aktionen (Methoden / Funktionen)
• aufeinander aufbauende Objekte (Vererbung)

Das sind sicher Hunderte von Details. Aber wenn Sie nur versuchen, jemandem einen Überblick über 10 Sekunden zu geben, denke ich, dass dies ein guter Anfang ist. Gibt es spezifischere Konzepte, die Sie nur schwer erklären können?

Das Handy-Beispiel:

Stellen Sie sich vor, Sie sind Fabrikbesitzer und möchten ein generisches Telefon beschreiben

• Schritt 1: Listen Sie die Eigenschaften dieses generischen Telefons auf, z. B.: Größe, Gewicht, Farbe usw.
• Schritt 2: Listen Sie diese allgemeinen Telefonfunktionen auf , z. B.: Anruf tätigen, Anruf empfangen, SMS senden usw.

Nachdem Sie Ihre generische "Blaupause" haben, erstellen Sie mir die folgenden Telefone:

Telefon 1:

• Höhe-> 102mm

• Gewicht-> 85g

• Farbe-> Pink

Telefon 2:

• Höhe-> 125mm

• Gewicht-> 96g

• Farbe-> Rot

Ich denke, der beste Weg, einem nicht-technischen Typ über OOP zu erklären, besteht darin, es mit ihnen in Beziehung zu setzen.

Im Wesentlichen möchte OOD & OOP, dass Sie über das System nachdenken, das Sie als Welt der Interaktion entwerfen und implementieren.

Nehmen wir zum Zwecke der Argumentation (die im Internet nie gut ankommt) an, Sie erklären einem Müllsammler etwas über OOD & P. Sein Name ist Bob. Sie sind vor 15 Jahren mit ihm zur Schule gegangen, haben ihn in einer Bar getroffen und täuschen beide vor, sich gegenseitig zu interessieren.

"Also, John, du sagst, du bist ein Programmierer. Mein Neffe steht auf all diesen Unsinn. Macht weiter mit objektorientierter Programmierung oder so. Worum geht es?" Beachten Sie, dass Bob Brite ist, weil er sich falsch geschrieben hat.

"Nun, Bob", antwortest du und krümmst dich orientiert. "Es ist wirklich ganz einfach. Du sammelst Müll, richtig? Was machst du im Allgemeinen in deinem Job?"

"Nun, ich folge dem Van durch die Stadt, sammle Müll auf und lege ihn in den Van", antwortet Bob fragend.

und darauf müssen Sie achten. Das sind unsere Verhaltensweisen. Das ist im Wesentlichen alles, was Sie für das Design benötigen. Objektorientierte Programmierung ist im Wesentlichen, wie Sie das Design implementieren. Es unterscheidet sich von Sprache zu Sprache. "

Bob ist in seinem Bier eingeschlafen. Du gehst weg.

Ich mag das Auto-Beispiel, um die Vererbung zu erklären (ich benutze eher Tiere als Fahrzeuge, aber es ist die gleiche Idee), aber um zu erklären, wie ein objektorientiertes Programm funktioniert, verweise ich auf eine Analogie, die ich einmal auf der Website von Chris Crawford gelesen habe: Das Programm ist wie eine wirklich effiziente Bürokratie. Alle verschiedenen Objekte im Programm sind wie die verschiedenen Abteilungen in einer Bürokratie; Jede Abteilung hat ihre eigenen Aufgaben, sie hat genau definierte Eingaben (mit wem sie sprechen und welche Formulare sie ausfüllen müssen) und andere Abteilungen wissen oft nicht so viel darüber, was im Inneren vor sich geht. HR ist wie eine abstrakte Fabrik, IT ist ein Singleton usw.

Das Erhalten einer Fehlermeldung, weil Sie das Falsche in ein Computerprogramm eingegeben haben, ist genau so, als würde man das Formular falsch ausfüllen, um es an ein Büro zu senden.

OOP ist eine grobe Vereinfachung - eine Abstraktion - des menschlichen Denkprozesses und des Verständnisses der Welt, um Funktionalität in eine digitale "Leere" zu projizieren, um vertraute Prozesse und Klassifikationen digital nachzuahmen. In vielerlei Hinsicht geht es mehr um unseren primitiven Sprachzustand als darum, dass wir "eher wie Computer denken".

Wenn das Programmieren die Realität oder das menschliche Denken nachahmt, ist es weitaus organischer, chaotischer und willkürlicher - sogar seitlich. Stattdessen vereinfachen wir die Realität in kleine Schritte, "2 + 2-Logik", grobe Kategorien, wiederverwendbare kleine Werkzeuge und prähistorisches Denken.

Wir versuchen immer noch herauszufinden, wie wir unsere Gedanken und Wünsche in ein Protokoll und eine gemeinsame Sprache herunterladen können, und ich denke, Historiker werden eines Tages von seiner raffinierten Grobheit fasziniert sein - so wie wir jetzt Hieroglyphen sehen. Es ist überhaupt nicht "klug" - es zeigt einfach, wie wir nicht einfach erklären können, wie wir selbst die einfachsten Dinge entscheiden oder verstehen. Das Rechnen befindet sich immer noch auf der Ebene der Gedankenentwicklung "Ein Hund ist ein Hund, weil es keine Katze ist" - es liegt Jahrtausende hinter der grundlegenden gesprochenen Sprache.

Es gibt zwei Arten von Zauberern. Da ist der Typ, der bestimmte Dinge mit magischen Worten geschehen lässt. Er hat ein Wort dafür, Feuer zu beschwören. Er hat ein Wort dafür, wie man ein gefrorenes Huhn aus der Luft erscheinen lässt. Und noch ein Wort für die Schaffung eines Krafttopfs (ich bevorzuge meine Kraft grün, leuchtend und durchscheinend) voller frolierender Güte. Mit der richtigen Anwendung seiner Worte kann er ein gebratenes Huhn produzieren.

Und dann ist da noch der OOP-Assistent. Wer ruft gerade einen Kobold herbei, der weiß, wie man in ein Lebensmittelgeschäft geht, ein Huhn kauft (oder Zutaten für jedes andere Essen, das er zubereiten soll), es kocht und Ihnen das Abendessen serviert. OOP Wizard muss seinem Kobold nicht sagen, wie es geht. Er muss ihn nur wissen lassen, was er will, in diesem Fall Brathähnchen. Darüber hinaus kann der OOP-Zauberer andere Schergen herbeirufen, um seinem Kobold-Chef zu sagen, was er tun soll.

Also, der Beschwörer beeindruckt auf Partys, aber der OOP-Assistent ist derjenige, den Sie wollen, wenn Sie ein magisches Restaurant mit einer Reihe von Charakteren eröffnen (wie zum Beispiel einem verärgerten Einhornkellner und einem Trollbodenmanager), die alle müssen zusammenarbeiten. Wenn Sie versuchen, jeden Schritt des Problems der Lösung von "Restaurant" aufzurufen, können Sie sich leicht in die Details verwickeln und es ist wirklich leicht, Fehler zu machen. Der OOP-Assistent trainiert seine Schergen vorab, um die Details für ihn zu klären, damit er sich darauf konzentrieren kann, das größere Problem zu lösen, indem er seine Leute interagieren lässt.

Ganz zu schweigen davon, dass es einfacher ist, Ihren Koch-Kobold für das Problem der Cafeteria in der Grundschule wiederzuverwenden, als den gesamten Müll zu trennen, den Sie möglicherweise wiederverwenden oder nicht, wenn Sie alles Schritt für Schritt tun, indem Sie Wörter aufrufen und Wörter, die andere Wortgruppen aufrufen (die immer zahlreicher werden, wenn Sie mit einer größeren Vielfalt von Problemen umgehen müssen).

Um fair zu sein, kann der Beschwörungsassistent mit sehr, sehr sorgfältiger Anwendung alles so schnell erledigen wie der OOP-Assistent. Er kann die Dinge auf die richtige Weise aufschlüsseln, so dass das Aufrufen der richtigen Zauber nicht mehr Arbeit von seiner Seite erfordert als der OOP-Assistent. Aber die Arbeit ist viel schwieriger zu verstehen oder zu duplizieren und viel schwieriger, große Teile davon wiederzuverwenden, da alles für ein bestimmtes komplexes Problem miteinander verbunden ist.