Wie kann man OO unterrichten, ohne auf reale Objekte zu verweisen? [geschlossen]

Ich erinnere mich, dass ich irgendwo gelesen habe, dass die ursprünglichen Konzepte hinter OO darin bestanden, eine bessere Architektur zu finden, um das Versenden von Daten zwischen mehreren Systemen auf eine Weise zu handhaben, die den Zustand dieser Daten schützt. Das ist wahrscheinlich eine schlechte Paraphrase, aber ich habe mich gefragt, ob es einen Weg gibt, OO ohne die Objektanalogien (Fahrrad, Auto, Person usw.) zu lehren, und der sich stattdessen auf die Messaging-Aspekte konzentriert. Wenn Sie Artikel, Links, Bücher usw. haben, wäre das hilfreich.

Das ursprüngliche Konzept von OO hat nichts mit dem zu tun, was das heutige OO ist. (Siehe Also, was hat Alan Kay wirklich mit dem Begriff "objektorientiert" gemeint? ) In der heutigen objektorientierten Programmierung geht es darum, Objekte wie die Metaphern von Fahrrädern, Häusern und Menschen usw. zu erstellen. Ich würde wärmstens empfehlen, bei diesen zu bleiben, da der Zweck der Metaphern darin besteht, den Menschen das Verständnis zu erleichtern, indem ein Konzept verwendet wird, das sie bereits verstehen. Helfen Sie ihnen, die Korrelation zu erkennen, und helfen Sie ihnen dann, die Unterschiede zu erkennen.

BEARBEITEN: In der heutigen OO geht es darum, vollständig in sich geschlossene Objekte zu erstellen, deren Eigenschaften und Fähigkeiten mit verschiedenen Methoden (Funktionen) und Attributen (Verweise auf AKA-Variablen und -Konstanten) vollständig / teilweise beschrieben werden.

Sie können über Konzepte der Kopplung und des Zusammenhalts sprechen. Objekte sollten aus Attributen und Methoden mit hoher Kohäsion und implizit hoher Kopplung bestehen. Sie sollten den Operationen und Attributen zugeordnet werden, die am wenigsten detailliert sind, damit das System funktioniert. Sie sollten auch den Wunsch erfüllen, den Code so klein und unkompliziert wie möglich zu halten, dh unter Berücksichtigung von Wartung und Erweiterbarkeit.

Dies verhindert auch "Objektexplosion", Überverallgemeinerung und falsche Metaphernwahl, die alle häufige Fehler sind.

Ich würde mich nicht auf die Objekte der realen Welt konzentrieren und ich würde mich auch nicht auf die Nachrichten konzentrieren. Ein Beispiel, das ich verwendet habe, sind Grafiken, in denen Sie Objekte haben möchten, die "wissen, wie man sich selbst zeichnet".

Wenn Sie beispielsweise in C arbeiten, in dem OO nicht integriert ist, empfiehlt es sich möglicherweise, Zeiger auf Funktionen in Datenobjekten zu speichern. Wenn Sie dies tun, keilen Sie sich in die OOP ein.

Ich beziehe mich nicht gerne auf Alan Kay, als ob er Moses wäre, der die Tabletten übergibt. Ich glaube eher, dass er in Mathematik und Bio ausgebildet wurde. Als Mathematiker hatte er wahrscheinlich eine gewisse Vertrautheit mit Lambda Calculus, der ziemlich abstrakt war und nichts mit Hardware zu tun hatte. In LC könnte man sagen, dass alles ein "Objekt" ist - wie die Nummer 0 und die Nummer 1 sind Objekte, die bei der Angabe eines Arguments zu unterschiedlichen Dingen ausgewertet werden. Das führt ziemlich gut zu Smalltalk. Die Idee von "message" ist, dass wir vermeiden können, über Hardware zu sprechen. Sie könnten sagen, wenn Sie eine Funktion (oder eine Methode eines Objekts) aufrufen, senden Sie ihr eine Nachricht, und wenn sie zurückkehrt, sendet sie Ihnen eine Nachricht (oder Ihrer Fortsetzung). Dies wurde verwendet, um Wege zur Kommunikation zwischen Programmen zu beschreiben, die asynchron auf separater Hardware ausgeführt werden. Das ist gut, aber für gewöhnliche Programmierung wird es hinreißend. Um den Wert der OOP-Idee zu ermitteln, müssen Sie weder die Relevanz der konkreten Aufgabe, die Sie ausführen möchten, noch die Konkretheit der Hardware, auf der Sie ausgeführt werden, leugnen. Ich denke, dass das Unterrichten über OOP in Form von erfundenen Analogien dazu führt, dass die Leute zu viel über Software-Design in Bezug auf die Datenstruktur nachdenken. Dies führt zu einem Überdesign, zu aufgeblähtem Code und massiven Leistungsproblemen, bei denen ich Zeit aufräumen muss es wird schlimm genug.

Ich würde behaupten, dass es kaum einen Unterschied gibt, ein physisches Objekt als Beispiel und ein nicht-physisches Objekt als Beispiel zu verwenden. Im Code haben beide genau die gleichen Teile. Wenn wir das Grafikbeispiel verwenden und es mit Kugel, Würfel, Zylinder lehren, ist es fast dasselbe wie mit Kugel, Kasten, Stange.

Um es zu lehren, ohne physische Beispiele zu verwenden, würde ich vorschlagen, überhaupt keine Beispiele zu verwenden, aber ich verstehe nicht, warum Sie keine physischen Beispiele möchten, so dass meine Haltung zu diesem Thema ist

Nein, Sie sollten es nicht ohne Gegenstände der realen Welt unterrichten

Ich sehe nicht , wie Sie vermeiden können , beginnen die in Metaphern der realen Welt, aber Sie wollen nicht bleiben dort. Wenn Sie OOP richtig machen, wird es schnell abstrakt, aber auf dieser nächsten Ebene des Verstehens sollte der Lernende Objekte als Objekte verstehen.

Interessanterweise sind einige meiner Lieblingsbeispiele keine physischen Objekte. Nehmen wir zum Beispiel das Bankkonto. Jeder "bekommt", warum Einzahlung () und Auszahlung () die Servicegebühr erheben sollten, anstatt sich auf den Anrufcode zu verlassen, um den Wert des Guthabens zu ändern, und daran zu denken, die Servicegebühr zu erheben. Formen auf einem Bildschirm sind doppelt immateriell, und Stroustrup sagte mir, dass das klassische "Formen" -Beispiel eines der beiden ältesten OO-Beispiele ist, die er kennt und die 40 Jahre zurückliegen (das andere sind Fahrzeuge, die jetzt 44 Jahre alt sind).

Wichtig ist, dass die Leute Ihre Beispiele sofort verstehen. Aufzüge sind nur für Personen ein gutes Beispiel, die alle mit Aufzügen vertraut sind. Etc.

Wenn Sie in einer Programmiergruppe sind, kommen Sie mit einigen Leuten zusammen und besprechen Sie, wie Sie sich gegenseitig anweisen würden, das zu tun, was das System tun muss. Nehmen Sie buchstäblich Rollen im System ein (Sie können dies alleine tun, indem Sie jede Rolle spielen, aber es ist einfacher mit einer Gruppe von Leuten. Spielzeug hilft, wenn Sie alleine sind). Konzentrieren Sie sich auf das, was jede Person tut / tun wird, und nicht auf die Daten, über die sie verfügt. Dies mit Menschen zu tun, hilft dabei, sich auf Nachrichten und Rollen zu konzentrieren, da sich die Menschen in der Regel an ihre Aktivitäten erinnern, nicht jedoch an die Daten, die sie haben.

Notieren Sie sich, wozu Sie sich gegenseitig auffordern müssen und welche Informationen Sie dazu benötigen. Schützen Sie Ihre eigenen Daten, wenn ein anderer Programmierer nach Ihren Daten fragt, sagen Sie "Nein" und fragen Sie ihn, warum er sie benötigt (hilft bei der Datenkapselung).

Ich denke, ein Bottom-Up / Metal-Ansatz könnte nützlich sein. Erklären Sie zunächst Strukturen und Zeiger im C-Stil, um zu zeigen, wie Daten strukturiert werden können, anstatt nur Primitive direkt zu verwenden. Erklären Sie dann die späten Bindungs- und Funktionszeiger. Erklären Sie dann, dass Sie diese verwenden können, um Objekte zu erstellen, die im Grunde gut gekapselte Datenstapel und Zeiger auf die Funktionen sind, die für die Verarbeitung dieser Daten erforderlich sind.

Diese Erklärung widerspricht der konventionellen mathematisch-wissenschaftlichen Methode, das Konzept unabhängig von der Implementierung zu lehren, aber es ist die Perspektive, die mich (zugegebenermaßen jemand mit einem Ingenieur-, nicht einem wissenschaftlich-technischen Hintergrund) dazu brachte, endlich OO zu bekommen.