物理的な現実世界のオブジェクトを参照せずにオブジェクト指向を教えるにはどうすればよいでしょうか？[閉まっている]

オブジェクト指向の背後にある元の概念は、データの状態を保護する方法で複数のシステム間でデータのメッセージングを処理するためのより良いアーキテクチャを見つけることであったことをどこかで読んだことを覚えています。今はおそらく貧弱な言い換えですが、オブジェクトの類推（バイク、車、人など）なしでオブジェクト指向を教える方法があり、代わりにメッセージングの側面に焦点を当てているのだろうかと思いました。記事、リンク、書籍などがある場合、それは役立ちます。

オブジェクト指向の元の概念は、今日のオブジェクト指向とは何の関係もありません。（「オブジェクト指向」という用語でアラン・ケイが本当に意味することは何ですか？を参照してください。）今日のオブジェクト指向プログラミングは、自転車や家や人などのメタファーのようなオブジェクトの作成に関するものです。メタファーの目的は、既に理解している概念を使用して人々が理解できるようにすることです。相関関係を確認し、その後、オブジェクト指向についてより深く掘り下げた違いを確認します。

編集：今日のオブジェクト指向は、さまざまなメソッド（関数）と属性（別名変数と定数）を使用して、プロパティと機能が完全/部分的に記述された完全な自己完結型オブジェクトを作成することです。

結合と結合の概念について話すことができます。オブジェクトは、高い凝集度と暗黙的に高い結合を持つ属性とメソッドで構成する必要があります。それらは、システムが動作するために必要な最小の粒度の操作と属性にマップする必要があります。また、コードをできる限り小さく簡単に保つという欲求、つまり、メンテナンスと拡張性を念頭に置いたコーディングも満たす必要があります。

これはまた、すべての一般的な間違いである「オブジェクトの爆発」、過剰な一般化、および誤ったメタファーの選択を防ぎます。

私は現実世界のオブジェクトには焦点を合わせませんし、メッセージングにも焦点を合わせません。むしろ、私が使用した例は、「自分自身を描く方法を知っている」オブジェクトを持ちたいグラフィックスです。

たとえば、OOが組み込まれていないCで作業している場合、データオブジェクト内に関数へのポインターを保存すると便利です。もしそうなら、あなたはOOPへの道を切り開いています。

私はあたかも彼がタブレットを伝えているモーゼであるかのように、アラン・ケイを参照するのは好きではありません。むしろ、彼は数学とバイオの訓練を受けていたと思う。数学者として、彼はおそらくラムダ計算にある程度精通していました。ラムダ計算は、ハードウェアとは関係なく、かなり抽象的でした。LCでは、すべてが「オブジェクト」であると言うかもしれません-数字の0や数字の1は、引数が与えられると異なるものに評価されるオブジェクトです。それはSmalltalkにかなりうまくつながります。「メッセージ」の考え方は、ハードウェアについて話すことを避けるためです。関数（またはオブジェクトのメソッド）を呼び出すとメッセージを送信し、戻るとメッセージを（またはあなたの継続に）送信すると言うことができます。これは、別々のハードウェアで非同期に実行されているプログラム間で通信する方法を記述する方法としてラッチされました。それはいいです、しかし、通常のプログラミングでは夢中になります。OOPアイデアの価値を得るために、実行しようとしている具体的なタスクの関連性を否定したり、実行しているハードウェアの具体性を否定したりする必要はありません。不自然な類推の観点からOOPを教えると、データ構造の観点からソフトウェア設計を考えすぎてしまい、設計が過剰になり、コードが肥大化し、パフォーマンスの問題が大きくなります。それは十分に悪くなります。

例として物理オブジェクトを使用する場合と、例として非物理オブジェクトを使用する場合にほとんど違いがないと主張します。コードでは、両者はまったく同じ部分を持っています。グラフィックの例を使用して、球、立方体、円柱を使って教える場合、ボール、箱、ポールを使用するのとほぼ同じです。

したがって、物理的な例を使用せずに教えるには、例をまったく使用しないことをお勧めしますが、物理的な例を必要としない理由がわかりませんので、トピックに対する私の姿勢は

いいえ、物理的な現実世界のオブジェクトなしで教えるべきではありません

現実世界のメタファーで始めることを避ける方法はわかりませんが、そこに留まりたくありません。OOPを正しく行うと、すぐに抽象化されますが、次のレベルの理解では、学習者はオブジェクトをオブジェクトとして理解する必要があります。

興味深いことに、私のお気に入りの例のいくつかは物理的なオブジェクトではありません。例として銀行口座を取り上げます。deposit（）とwithdraw（）が残高の値を変更するために呼び出しコードに依存するのではなく、サービス料を請求する理由を誰もが「理解」し、サービス料を忘れないようにします。画面上の図形は二重に無形であり、Stroustrupは古典的な「Shapes」の例は彼が知っている2つの最も古いOOの例の1つであり、40年前にさかのぼります（もう1つは44歳の車両です）。

重要なのは、人々があなたの例をすぐに理解することです。エレベーターは、エレベーターに精通している人にのみ良い例です。等。

プログラミンググループに参加している場合は、何人かの人を集めて、システムに必要なことを行うように互いに伝える方法について話し合います。文字通り、システム内で役割を果たします（各役割を演じるだけでこれを自分で行うことができますが、グループで行う方が簡単です。自分でいる場合はおもちゃが役立ちます）。どのデータを持っているかではなく、各人が何をしているか、何をしようとしているのかに集中してください。人々と一緒にこれを行うと、メッセージや役割に焦点を当てるのに役立ちます。人々は自分がしていることを覚えているが、持っているデータは覚えていないためです。

互いに依頼しなければならないこと、およびそれを行うために必要な情報をメモします。他のプログラマがあなたのデータに何かノーと言って、彼にそれが必要な理由を尋ねる場合、あなた自身のデータを保護してください（データのカプセル化に役立ちます）。

ボトムアップ/メタルアプローチが役立つと思います。まず、プリミティブを直接使用するのではなく、データをどのように構造化できるかを示すために、Cスタイルの構造体とポインターを説明します。次に、遅延バインディングと関数ポインターについて説明します。次に、これらを使用してオブジェクトを構築できることを説明します。オブジェクトとは、基本的にカプセル化されたデータの山であり、データの操作に必要な関数へのポインターです。

この説明は、実装とは無関係に概念を教える従来の数学/ comp sciの方法と矛盾しますが、それは私（明らかに、comp sciではなく、エンジニアリングのバックグラウンドを持つ人）が最終的にオブジェクト指向を取得した視点です。