Fortran 77のみでコーディングされている人にオブジェクト指向プログラミングを説明するにはどうすればよいですか？

私の母はFortranで大学の論文を書いており、現在（10年以上後）流体シミュレーションのためにc ++を学ぶ必要があります。彼女はすべての手続き型プログラミングを理解できますが、オブジェクトを説明しようとしても、それは固執しません。（私はJavaで多くの仕事をしているので、オブジェクトがどのように機能するかを知っています）私はそれをあまりにも高レベルの方法で説明しているかもしれないと思うので、まったく一緒に仕事をしたことがなく、成長した人には本当に意味がありません純粋に手続き型プログラミングの時代に。

彼女が理解するのに役立つ簡単な方法を彼女に説明できますか？

短い答え：いいえ。

長い答え：OOPは単純ではないため、「単純な方法」はありません。手続き型プログラミングは、すべて「変数」と「if then goto」に関するものです。他のすべては構文糖ですが、これらの4つのことは、手続き型プログラミングのすべてです。それらを取得したら、何もあなたを止めることはできません。

OOPは、変数とコードを整理する方法です。OOPを定義するためのパターンはいくつありますか？25？30？さまざまな言語や背景からOOPを学んだ教師でさえ、独自の定義に同意していません。

どうやってそこに来たのかわかりませんが、あなたのお母さんは私の経験と似ているので、どうやってそこに来たか教えてください。

私は非常に大きなプロジェクトでCでプログラミングしていました。それは1988年でした。多くのプログラマーがモジュールとライブラリを編成し、他のジョブへの干渉を避け、職務を適切に分離するのが困難でした。

相互に関連するすべてのグローバルデータを構造体に入れ、コールバックが必要な関数ポインターを構造体に配置する「解決策」に到達しました。私たちはそのようにio_mask（テキストモードのダイアログボックスの種類）graphic_managerなどと呼ばれるものを一般化しました。

1996年、これらの構造体は「クラス」と名付けられ、それらの関数ポインターはメンバー関数と仮想関数、またはその古いプロジェクトを更新した他のプログラマーによる他のオブジェクトへのリンク（ビヘイビアと呼ばれる）に置き換えられたことを発見するのは非常に簡単でした。

OOP の必要性を感じ始めたとき、OOPを理解し始めました：分離、ポリモーフィズム、およびランタイム定義の動作。

今日私はOOPで働いていますが、私はそれを奉仕する教義とは考えていません：長い説明と説明を常に提供する必要なしに一緒に話すことができる単なる「一般的なイディオム」（...のセット） 。実際、何よりも「慣習」です。結局のところ、OOPが行うことはすべて、再び「if then goto」であり、単に「多層化」されます。したがって、イディオムに対する抽象化とイディオム。

それらを無視します。彼女がそれらの必要性を感じるまで、説明しようとさえしません。彼女はそれらを単純なことをするための複雑な方法として感じるでしょう。そして彼女は正しいです...彼女がやることが-事実-シンプルになるまで。

トップに4つしかない場合、誰も「机を整理する」とは思わないでしょう。上にあるものが互いに干渉し始めるとき、それは理にかなっています。それが、OOPが登場する時です。

C ++で作業するためにOOPは必要ありません。C ++標準ライブラリ全体は、OOPの観点からは設計されていません（ただし、連携できますが）。C++はJavaではありません。

私の経験では、最悪のC ++教師とC ++プログラマーはJavaから来た人であり、すべてについて偏見を教えるのはOOPではありません。

C ++：Accelerated C ++にアプローチしたい人のために良い本を提案させてください。事前定義された教義に従うふりをせずに、C ++のイディオムを紹介します。

古い友人は、私が彼がオブジェクト指向プログラミングについて知っている最短の定義を持っていると主張しました、そして、私はそれが一部の人々のために（そして他の人のために）働かないことがわかりました：

オブジェクト指向プログラミングは意見のあるデータです。 あなたは椅子を動かさず、椅子に自分自身を動かすよう頼みます。リストをソートするのではなく、リストをソートするように依頼します（おそらくヒントを使用して）。等。

その考えは、プログラムの中で物事がどのように行われるかについて、人に違った考え方をさせることです。

実世界のオブジェクトのようなオブジェクトを考えるように彼女に伝えます。たとえば、全世界はオブジェクト指向プログラミング（C ++）と何らかの関数型プログラミング（おそらく神の言語であるLispで行われます）を混在させることができます。

芝刈り機などのオブジェクトを取ります。オブジェクトには特定の属性があり、特定の処理を実行できます。（オブジェクトとクラス）

次に、あなたがすでに持っている芝刈り機の延長であるより良い芝刈り機について彼女に話します。その方が良いと伝えますが、それでも同じメカニズム（継承）に基づいています。

それから彼女にあなた自身について話してください。芝刈りの専門家になることもありますが、実際はプログラマーであり、生計を立てていることを彼女に伝えてください。これは、同時に2つの異なるエンティティとして行動するようなものです。これはポリモーフィズムです。

彼女がこれを取得するまでに、学習しなければならない言語（C ++）でこれらのことを実装する方法を彼女に伝えてください。

それから彼女に、もし彼女がコンピューターの世界でこの世界のシミュレーションを書かなければならないなら、彼女はそれをする方法を学ばなければならないでしょう。

彼女が現実世界の考えをプログラムコードに変換する方法を知っているとき。彼女はオブジェクト指向プログラミング言語でプログラミングする方法を学んでいたでしょう。

アセンブラーとCOBOLからRubyに移行しました。

最初に助けになったのは、インスタンスを作成するクラスの概念を実際に無視していたことです。

コードから始めてください。クラスを持ちますが、クラスレベルのメソッドだけがあります。メソッド内では、パラメータ、変数、条件、配列、文​​字列、ブール値などに関するものが多くあります。このようなものはおなじみのはずです。

したがって、この時点では、クラスは、関連するすべてのメソッドを配置する場所としての目的を果たしていると見なすことができます。これをコンテナまたはライブラリと呼ぶことは、彼女にとってより馴染みのあるものです。

明らかに、管理しやすいようにコードをセグメント化する必要があるので、これらの各領域の1つがあります。たとえば、PCでユーティリティプログラムのセットを管理するために、電卓のすべてのコードを1か所に配置できる電卓クラスがあります。PCに計算機が1つしかない場合は、クラスレベルのメソッドで十分です。

それが始まりです。

では、複数の電卓を開き、それぞれの表示方法と画面上の位置を変更するという事実を考慮してください。したがって、「screen_location」などの電卓メソッドを複数持つことはできません。各インスタンスには独自の場所があります...各インスタンス... OK、インスタンスが必要です。

注：私の用語はC ++ではなくrubyのものであるため、翻訳が必要になる場合があります。

概念をどの程度分割したいかに応じて、2段階、または4段階で説明します。

ステップ1：彼女を構造物に紹介します。Fortranデータ型から構造体へのかなり小さなステップです。ステップ1a：動的メモリの割り当てとポインタが標準よりも低いことを確認します。

ステップ2：それらの構造にのみ関連付けられたプロシージャを追加します。ステップ2a：小さな構造を「ラップ」する大きな構造の構築に基づいて継承を追加します。

Fortranプログラマーにとって、「すごい」要因は、コンパイラーが追跡することが非常に多いことです。うん。それがコンパイラの目的です...

10年前に論文を書いたなら、おそらくFortan 90または95を使っていたでしょう。その場合、派生データ型との関係でFortan 90または95について話しています。彼女がFortran 77を使用したのが十分に前の場合、Fortran 90の派生データ型を彼女に紹介し、それについて話します...

彼女がカプセル化を理解するまで、それらは特別なケースとカプセル化の拡張として見ることができるので、ポリモーフィズムと継承には行きません。私はおそらく、無料の関数または静的クラスを許可する言語で彼女を始めるでしょう。

彼女が構造を理解したら、次の重要なポイントは、オブジェクト指向プログラミングが、物が渡される可能性のある一連のメソッドを、実際に適用できる一連のメソッドに限定する手段として機能することを認識することだと思います事。

非オブジェクト指向プログラミングでは、TreeとLinkedListに別々のデータ型を使用している場合、それぞれにノードを追加するために異なるメソッドを使用する必要があります。非オブジェクト指向言語は、一般的に、1つは、両方の方法を命名しようとした、スコークならばAddItem、任意の名前が1つの方法だけを参照することができますので、これのようなメソッド名を作成するために1をリードし、AddTreeItem、AddLinkedListItem、RemoveTreeItem、などのようなアプローチの作品を、それは少しです醜い。概念的には、メソッドAddTreeItemとRemoveTreeItemは一緒に属するように見えますが、名前はそのようには分類されません。一つは、などの名前を書き換えることができTreeAddItem、TreeRemoveItem、LinkedListAddItem、など。ただし、それは各メソッド呼び出しの開始時に多くの「冗長ノイズ」を配置します。典型的なプログラムのメソッド呼び出しの大部分には、3つの重要な情報が含まれます。（1）メソッドを含むソースコードのセクション。（2）セクションのどの方法が使用されているか。（3）どのデータが作用されていますか？多くの場合、処理されるデータのタイプは、メソッドが属するコードセクションを識別するのに十分であるため、上記のパート（1）は冗長です。他の資料よりも声明の冒頭で資料を視覚的に識別する方が簡単です。そのため、コーディング/命名スタイルTreeAddItem(myTree, whatever)は、最も有用でない情報をプライムスポットに配置することになります。

これとは対照的に、オブジェクト指向プログラミングを使用するとTree.AddItem、メソッドになどの名前を効果的に付けmyTree.AddItem(whatever)、基本的に「Hmm ... myTreeは型なTreeので、このコードを呼び出す必要がありTree.AddItem()ます。指定したTree.呼び出し時にAddItemコンパイラがの種類知っているのでmyTree。概念的に、のような文がmyTree.AddItem(whatever)に相当しTree.AddItem(myTree, whatever)、そしていくつかのオブジェクト指向言語が同等に両方の形式を可能にすることができる。実際には、ほとんどの言語は、機能仕様から最初のパラメータを省略し、代わりに持っています以下のようなクラスで定義されたメソッドは、Tree暗黙的に型のパラメータを取るTree、とのように、名前を割り当てるthis、selfまたはMe。

多くの場合、オブジェクト指向プログラミング言語には、多くのアプリケーションで非常に役立つ継承、仮想関数などのさまざまな追加機能が含まれていますが、それらの機能がなくても、操作対象に従って機能をグループ化する機能は非常に便利です。

ここで関連するクラス指向の意味でのオブジェクト指向プログラミングは、データ表現を操作するコードと結合することです。次のことが理にかなっている場合、それは理にかなっています：

• カップリング：操作対象のデータ表現とともに操作を定義する

• 遅延バインディング：実行時のデータ表現と動作の組み合わせの選択

• カプセル化：データが構造上有効であり、後で無効にならないようにする

それで全部です。同様に任意の技術、その心臓部には、単に多くの開発が後に続いているから便利、です。基本を理解したら、残りはやがて続きます。

BlueJをダウンロードし、20分間遊んでから20分間遊んでみることをお勧めします。

クラス、インターフェース、および継承を視覚化する方法は非常に明白で直感的であるため、何かを実装するとすぐに理解できます。

クラスとオブジェクトの違いを直接示します

オブジェクト指向の設計パターンに関する深い洞察は得られませんが、概念の素晴らしい概要は得られます。

プログラミングパラダイムとこれらのパラダイムを実装するプログラミング言語の違いを思い出させるものとして、私の貢献を加えたいと思います。

したがって、私の意見では、C77を使用したオブジェクト指向をF77ユーザーに説明する最良の方法は、段階的な方法で進めることです。

まず、Fortran 77でオブジェクトのような構造を開発する方法を示すことにより、ユーザーに使い慣れた設定でオブジェクト指向の概念を紹介します。たとえば、B。Pattonのような論文を見てください。 view）」SIGPLAN Fortran Forum 12、2（1993）、pp。23-24、およびその参考文献。

次に、これらの構造とC ++クラスおよびメソッドとの対応を確立します。

最後に、オブジェクト指向プログラミングを促進するためにC ++が提供できる追加機能について説明します。

Pascalでの最初のトレーニングからオブジェクト指向言語に初めて移行したとき、「。」問題も私にとって最大のハードルでした。それを乗り越えるのに何年もかかりました。

変数を別の変数に所属させることは、特にポインターとして考えることに慣れている場合、実際には直感的ではありません。私にとっての障害は次のとおりです。

• 基本的にポインターであり、それを指す別のポインターを持ち、親ポインターとは異なるものに解決するものにとって、それはどういう意味ですか？

私にとっては、トップレベルのポインターが基本的に名前空間にすぎないことに気付いた瞬間です。

理想的にはドット表記を使用せずに、関数の名前空間を指定する必要があるコードの束を彼女に書かせることをお勧めします。次に、ドット表記を使用して、彼女にそれを書き直してもらいます。

そのエクササイズを行うと、彼女は最初の「これはどんな魔術ですか？」ハードル。

以前の説明に役立った重要な洞察の1つは、クラスの複数のインスタンスを持つことができるという事実です。それを「図面」または「型」と「コピー」の観点から説明し、それがどこにでもつながるかどうかを確認してください。