OOPの忘れられた歴史

今日使用しているプログラミングパラダイムのほとんどは、1930年代に、ユニバーサルコンピューティングモデルのバリエーションであるラムダ計算とチューリングマシンのアイデアを使用して数学的に研究されました（これらは汎用計算を実行できる形式化されたシステムです）。 Church-Turing論文は、ラムダ計算とチューリングマシンが機能的に同等であることを示しました。 つまり、チューリングマシンを使用して計算できるすべてのものは、ラムダ計算を使用して計算でき、その逆も同様であるという事実について話しているのです。







チューリングマシンが計算可能なすべてを計算できるという一般的な誤解があります。 チューリングマシンを使用して計算できる問題のクラス（たとえば、 停止の問題など ）がいくつかあります。 このテキストで「計算可能」という言葉が使用されている場合、「チューリングマシンによる計算可能」という意味です。



ラムダ計算は、トップダウンベースで計算に関数を適用するアプローチを示しています。 チューリングテープマシンは、ボトムアップベースで実装される、コンピューティングへの不可欠な（ステップバイステップ）アプローチです。



マシンコードやアセンブラなどの低レベルプログラミング言語は1940年代に登場し、1950年代の終わりには、機能的アプローチと命令型アプローチの両方を実装した最初の人気の高レベル言語が登場しました。 そのため、Clojure、Scheme、AutoLispなど、Lisp言語の方言はまだ広く使用されています。 50年代には、FORTRANやCOBOLなどの言語が登場しました。 それらは、まだ生きている命令型の高レベル言語の例です。 Cファミリーの言語は、ほとんどの分野で、COBOLとFORTRANの両方を置き換えたことに注意する必要があります。



命令型プログラミングと関数型プログラミングのルーツは、コンピューティングの正式な数学にあり、デジタルコンピューターの前に登場しました。 オブジェクト指向プログラミング（OOP）は後に登場しました;これは、前世紀の60年代と70年代に起こった構造プログラミング革命に由来します。



私が知っていた最初のオブジェクトは、1961年から1962年の間に作成された彼の運命的なアプリケーションSketchpadでIvan Sutherlandによって使用されました。 オブジェクトは、オシロスコープ画面に表示されるグラフィックキャラクターであり（おそらく、グラフィカルコンピューターモニターを使用した史上初めて）、ダイナミックデリゲートを介した継承をサポートしています。IvanSutherlandは、彼の作品で「マスター」と呼びました。 任意のオブジェクトがマスターオブジェクトになる可能性があり、オブジェクトの追加のインスタンスは「発生」と呼ばれました。 これにより、Sketchpadシステムはプロトタイプ継承を実装した有名なプログラミング言語の最初の所有者になりました。



一般に「オブジェクト指向」として知られる最初のプログラミング言語はSimula言語で、その仕様は1965年に開発されました。 スケッチパッドと同様に、Silmulaはオブジェクトの操作用に提供されていましたが、クラス、クラスベースの継承、サブクラス、仮想メソッドも含まれていました。



仮想メソッドは、サブクラスが再定義するように設計されたクラスで定義されたメソッドです。 仮想メソッドを使用すると、プログラムは、動的ディスパッチを使用して実行時に呼び出す特定のメソッドを決定することにより、コードのコンパイル時に存在しない可能性のあるメソッドを呼び出すことができます。 JavaScriptには動的な型があり、委任チェーンを使用して呼び出すメソッドを決定するため、この言語ではプログラマーに仮想メソッドの概念を導入する必要はありません。 つまり、JavaScriptのすべてのメソッドは実行時にディスパッチを使用するため、この機能をサポートするためにJavaScriptのメソッドを「仮想」と宣言する必要はありません。

OOPについてのOOP父親の意見

「オブジェクト指向」という用語を作り出しました。「C ++を意味するものではなかったと言えます。」 アラン・ケイ、OOPSLA Conference、1997。



Alan Kayは、プログラミング言語Smalltalk（1972）を指す「オブジェクト指向プログラミング」という用語を生み出しました。 この言語は、Dynabookデバイスプロジェクトの一環として、Alan Kay、Dan Ingles、およびXerox PARC Research Centerの他の従業員によって開発されました。 SmalltalkはSimulaよりもオブジェクト指向でした。 Smalltalkでは、クラス、整数、ブロック（クロージャ）など、すべてがオブジェクトです。 言語の初期実装であるSmalltalk-72には、サブクラス化する機能がありませんでした。 この機能はSmalltalk-76で登場しました。



Smalltalkはクラスをサポートし、その結果、サブクラス化を行いましたが、Smalltalkはこれらのアイデアを最前線に置きませんでした。 LispがSimulaと同じくらい影響を与えた関数型言語でした。 Alan Kayによると、クラスをコード再利用メカニズムとして扱うのは間違いです。 プログラミング業界は、サブクラスの作成に多大な注意を払っており、オブジェクト指向プログラミングの真の利点から逸れています。



JavaScriptとSmalltalkには多くの共通点があります。 JavaScriptは、OOPの概念を誤解したことに対するSmalltalkの世界への復geと言えます。 これらの言語は両方とも、次の機能をサポートしています。

• オブジェクト
• ファーストクラスの関数とクロージャー。
• 動的タイプ。
• 遅延バインディング（関数とメソッドはプログラム実行中に置き換えることができます）。
• クラスベースの継承システムのないOOP。

「私は、この現象の用語「オブジェクト」を思いついたのはかなり前です。なぜなら、その使用は、多くの人々が主要なものほど重要ではないアイデアを主に重要視するという事実につながるからです。 主なアイデアはメッセージングです。」 アラン・ケイ



2003年の電子メール通信で 、アランケイは、Smalltalkを「オブジェクト指向言語」と呼んだときに彼が念頭に置いていたことを明確にしました。



「私にとって、OOPとは、メッセージング、ローカルストレージ、保護、非表示状態、および非常に遅いバインディングのみを意味します。」 アラン・ケイ



言い換えれば、アランケイのアイデアに沿って、最も重要なOOP成分は次のとおりです。

• メッセージング
• カプセル化。
• 動的リンク。

「OOP」という用語を発明して大衆に持ち込んだアラン・ケイは、継承と多型をOOPの最も重要な要素とは考えていなかったことに注意することが重要です。

OOPの本質

メッセージングとカプセル化の組み合わせは、いくつかの重要な目的を果たします。

• 状態をカプセル化し、状態のローカルな変更から他のオブジェクトを分離することにより、オブジェクトの共有可能な可変状態を回避します。 別のオブジェクトの状態に影響を与える唯一の方法は、（コマンドを与えるのではなく）彼にメッセージを送信して変更するよう依頼することです。 状態の変化はローカルのセルレベルで制御され、状態は他のオブジェクトからは利用できません。
• オブジェクトの相互分離。 メッセージの送信者は、メッセージングAPIを介して受信者に疎結合されます。
• 遅延バインディングによるプログラム実行中の変更に対する適応性と抵抗。 プログラムの実行中に変更に適応すると、Alan KayがOOPにとって非常に重要だと考える多くの重要な利点が得られます。

これらのアイデアを表明したアランケイのインスピレーションの源は、生物学に関する知識と、ARPANET（これはインターネットの初期バージョンです）について知っていたことです。 つまり、私たちは生体細胞と、ネットワークに接続された個々のコンピューターについて話しているのです。 それでも、Alan Kayはプログラムが巨大な分散コンピューター（インターネット）上でどのように動作するかを想像しましたが、個々のコンピューターは生物細胞のように振る舞い、独立した独自の状態で動作し、メッセージを送信して他のコンピューターとデータを交換します



「私は、細胞またはコンピューターのメタファーがデータの除去に役立つことを認識しました[...]。」 アラン・ケイ



「データの削除に役立つ」と言うと、Alan Kayはもちろん、共有可能な可変状態に起因する問題と、データ共有に起因する強力な接続性を認識していました。 今日、これらのトピックは広く聞かれています。 しかし、1960年代後半、ARPANETプログラマーは、プログラムを開発する前に、プログラムのデータモデル表現を選択する必要性に不満でした。 開発者は、事前にデータの表示によって定義されたフレームワークに自分自身を追い込んだため、将来何かを変更することはより困難であるため、このプラクティスから逃れたいと考えていました。



問題は、データにアクセスするためのさまざまな方法、データへのアクセス、ある時点で使用されるプログラミング言語の異なるコードおよび異なる構文が必要ということでした。 ここでの聖杯は、データにアクセスして管理する普遍的な方法です。 すべてのデータがプログラムで同じに見える場合、プログラムの開発と保守に関する開発者の多くの問題を解決します。

アラン・ケイは、ある意味で、どのデータとプログラムが独立したエンティティであるかによって、アイデアを「取り払おう」としました。 それらは、リストまたはSmalltalkではそのようなものとは見なされません。 データ（値、変数、データ構造など）を使用して実行できることと、関数のようなソフトウェア構成との間には分離がありません。 関数は「一流の市民」であり、プログラムは実行中に変更できます。 言い換えると、Smalltalkはデータと特別な特権関係を持ちません。



さらに、アランケイは、オブジェクトを代数的構造と見なし、オブジェクトの動作について明確で数学的に証明可能な保証を与えました。



「数学的な背景から、各オブジェクトには複数の代数モデルを関連付けることができ、類似したモデルのグループ全体が存在し、非常に有用であることが理解できました。」 アラン・ケイ



それがそうであることが証明され、これが約束やレンズなどのオブジェクトの基礎を形成し、さらに、カテゴリー理論は両方の影響を受けました。

Alan Kayがオブジェクトを見た方法の代数的性質は、代数モデルが本質的に方程式の形でいくつかの規則に従う操作であるため、オブジェクトが形式的な検証、決定論的な動作を提供し、テスト容易性を改善することを可能にします。



プログラマの専門用語では、「代数モデル」は、特定のルールを伴う関数（操作）から作成された抽象化であり、これらの関数がパスする必要のある単体テスト（軸、方程式）によって実施されます。



これらのアイデアは、C ++、Java、C＃などを含むCファミリのほとんどのオブジェクト指向言語で何十年も忘れられてきました。 しかし、これらのアイデアは、最も広く使用されているオブジェクト指向言語の最近のバージョンで、リターンジャーニーの検索を開始します。



この機会に、プログラミングの世界は関数型プログラミングの利点を再発見し、オブジェクト指向言語のコンテキストで合理的な議論を提供すると誰かが言うことができます。



以前のJavaScriptやSmalltalkのように、ほとんどの最新のオブジェクト指向言語はますます「マルチパラダイム」になりつつあります。 関数型プログラミングとOOPを選択する理由はありません。 これらのアプローチのそれぞれの歴史的本質を見ると、それらは互換性があるだけでなく、補完的なアイデアとしても見えます。



アランケイの考えによると、PLOで最も重要なことは何ですか？

• カプセル化。
• メッセージング
• 動的バインディング（プログラムが実行中に変更を開発し、それに適応する能力）。

OOPで無視できるものは何ですか？

• クラス。
• クラスベースの継承。
• オブジェクト、関数、またはデータとの特別な関係。
• キーワードnew
  
  
  
  。
• 多型。
• 静的型付け。
• 「タイプ」としてのクラスに対する態度。

JavaまたはC＃を知っている場合、静的型付けまたはポリモーフィズムがOOPの最も重要な要素であると考えるかもしれませんが、Alan Kayは代数形式の普遍的な動作パターンを扱うことを好みます。 Haskellで書かれた例を次に示します。

 fmap :: (a -> b) -> fa -> fb
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、未定義のタイプa



およびb



で機能する汎用map



ファンクタのシグネチャであり、ファンクタb



のコンテキストで関数b



からb



を適用してファンクタb



を作成します。 「ファンクター」は数学の専門用語からの言葉であり、その意味は「表示操作のサポート」に限定されます。 JavaScriptの[].map()



メソッドに精通している場合は、これが何を意味するか既に知っています。



以下にJavaScriptの例をいくつか示します。

 // isEven = Number => Boolean const isEven = n => n % 2 === 0; const nums = [1, 2, 3, 4, 5, 6]; //  map   `a => b`    `a` ( `this`) //     `b` //    `a`   `Number`,   `b`  `Boolean` const results = nums.map(isEven); console.log(results); // [false, true, false, true, false, true]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

.map()



メソッドは、 b



とb



が任意のタイプであるという意味で普遍的であり、配列はファンクターの代数則を実装するデータ構造であるため、このメソッドは問題なくこの状況に対処します。 .map()



のタイプは重要ではありません。このメソッドは対応する値を直接処理しようとしないためです。 代わりに、アプリケーションの観点から正しい対応する型の値を期待して返す関数を使用します。

 // matches = a => Boolean //  `a`    ,   const matches = control => input => input === control; const strings = ['foo', 'bar', 'baz']; const results = strings.map(matches('bar')); console.log(results); // [false, true, false]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ユニバーサルタイプの関係は、TypeScriptのような言語で正確かつ完全に表現するのが難しい場合がありますが、Haskellで使用されるHindley-Milnerタイプシステムで行うのは非常に簡単です。



ほとんどの型システムは、関数の構成、オブジェクトの自由な構成、プログラム実行中のオブジェクトの拡張、コンビネーター、レンズなどの使用など、動的で機能的なアイデアの自由な表現を可能にするほど強力な制限を課します。 言い換えれば？ 静的型は、多くの場合、ビルドメソッドを使用したソフトウェアの作成を困難にします。



型システムに制限が多すぎる場合（TypeScriptやJavaなど）、より自由なアプローチで言語を使用する場合よりも同じ目標を達成するために、より複雑なコードを記述する必要があります。 これは、静的型の使用が不幸な考えであることや、静的型のすべての実装に同じ制限があることを意味するものではありません。 たとえば、Haskell型システムでの作業で発生する問題ははるかに少なくなっています。



あなたが静的タイプのファンであり、制限に反対していない場合、私はあなたにキールの下に7フィートを望みます。 しかし、他の関数と複合代数構造を合成することによって得られた関数を入力するのが容易ではないという事実のために、ここで表現されたアイデアのいくつかが実装するのが難しいとわかった場合、アイデアではなく型システムを非難してください。 ドライバーは、フレームフレームSUVが提供する快適さを好むが、飛行しないと文句を言う人はいない。 飛ぶには、より自由度の高い乗り物が必要です。



制限によりコードがシンプルになる場合-すばらしい！ しかし、制約がより複雑なコードを書くことを強制する場合、おそらくこれらの制約に何か問題があります。

「オブジェクト」とは何ですか？

「オブジェクト」という言葉は、時間の経過とともに、意味の多くの二次的な意味合いを獲得しています。 JavaScriptで「オブジェクト」と呼ぶものは、クラスベースのプログラミングやAlan Kayのメッセージパッシングのアイデアのヒントを一切持たない単なる複合データ型です。



JavaScriptでは、これらのオブジェクトは、カプセル化、メッセージの受け渡し、メソッドによる動作の分離、さらにはサブクラスを使用したポリモーフィズム（タイプベースのディスパッチではなく委任チェーンを使用）をサポートできます。



Alan Kayは、プログラムとそのデータの違いを取り除きたいと考えていました。 JavaScriptは、データを格納するプロパティと同じ場所にオブジェクトメソッドを配置することで、ある程度この目標を達成します。 たとえば、任意のプロパティに任意の機能を割り当てることができます。 オブジェクトの動作を動的に構築し、プログラムの実行中にオブジェクトのセマンティックコンテンツを変更できます。



オブジェクトは単なる複合データ構造であり、オブジェクトと見なされるために特別なものは必要ありません。 ただし、関数を使用してもコードが「機能する」わけではないのと同様に、オブジェクトを使用したプログラミングでは、そのようなコードが「オブジェクト指向」であるという事実にはつながりません。

OOPは実際のOOPではなくなりました

現代のプログラミング言語の「オブジェクト」の概念はアランケイが意味するものよりもはるかに少ないことを意味するため、このOOPのルールを説明するために「オブジェクト」という言葉の代わりに「コンポーネント」という言葉を使用します。 多くのオブジェクトは、サードパーティのJavaScriptコードによって直接所有および管理されますが、コンポーネントは独自の状態をカプセル化し、制御する必要があります。



実際のOOPとは次のとおりです。

• コンポーネントを使用したプログラミング（Alan Kayは「オブジェクト」と呼びます）。
• コンポーネントの状態をカプセル化する必要があります。
• エンティティ間の通信には、メッセージングが使用されます。
• コンポーネントは、実行時に追加、変更、および置換できます。

ほとんどのオブジェクトの動作は、代数的データ構造を使用して普遍的な方法で指定できます。 継承の必要はありません。 コンポーネントは、データを公開せずに、パブリック関数からの動作を再利用し、モジュールをインポートできます。



JavaScriptでオブジェクトを操作したり、クラスベースの継承を使用したりすることは、誰かがOOPプログラミングに関与しているという意味ではありません。 しかし、そのような方法でのコンポーネントの使用-を意味します。 しかし、用語に関する確立されたアイデアを取り除くのは非常に難しいので、おそらく「OOP」という用語を残して、上記の「コンポーネント」を「メッセージ指向プログラミング（MOP）」として使用する必要があります。 メッセージ指向プログラミングについては、以下の「MOP」という用語を使用します。



たまたま、英語の単語「mop」は「mop」と翻訳されており、ご存じのように、順序を復元するために使用されています。

良いMOPはどのように見えますか？

最新のプログラムのほとんどには、ユーザーとのやり取りを担当する特定のユーザーインターフェイス（ユーザーインターフェイス、UI）、アプリケーションの状態（ユーザーデータ）の管理に忙しいコード、およびシステムで動作するかネットワークとのデータ交換を担当するコードがあります。



これらの各システムの動作をサポートするには、イベントリスナーなどの長期間有効なプロセスが必要になる場合があります。 ここでは、アプリケーションの状態が必要になります-ネットワーク接続に関する情報、インターフェースコントロールの状態、アプリケーション自体に関する情報などを保存するために。



優れたMOPとは、そのようなすべてのシステムが相互の状態にアクセスして直接制御できるのではなく、メッセージを介して相互作用することを意味します。 ユーザーが「保存」ボタンをクリックすると、 "SAVE"



メッセージを送信できます。 状態管理アプリケーションコンポーネントは、このメッセージを解釈し、状態からの更新を担当するプロセッサ（純粋なレデューサー関数など）にリダイレクトできます。 おそらく、状態を更新した後、状態の管理を担当するコンポーネントは、メッセージ"STATE_UPDATED"



ユーザーインターフェイスコンポーネントにディスパッチします"STATE_UPDATED"



ユーザーインターフェイスコンポーネントは、状態を解釈し、インターフェイスのどの部分を更新する必要があるかを決定し、更新された状態を操作するサブコンポーネントに転送します特定のインターフェース要素。



一方、ネットワーク接続を担当するコンポーネントは、ネットワーク上の別のコンピューターへのユーザーの接続を監視し、メッセージをリッスンし、状態の更新されたビューをディスパッチしてリモートマシンに保存できます。 同様のコンポーネントは、ネットワークメカニズムの操作を担当し、接続が機能しているかどうかを認識しています。



同様のアプリケーションシステムは、他の部分の詳細を知らないはずです。 彼らは自分の問題を解決することだけに注意を払うべきです。 システムコンポーネントは、コンストラクターとして分解およびアセンブルできます。 それらは標準化されたインターフェースを実装します。つまり、相互にやり取りすることができます。 コンポーネントのインターフェースに関するよく知られた要件が満たされている限り、そのようなコンポーネントは同じインターフェースを持つ他のコンポーネントに置き換えることができますが、同じ方法で別の方法で実行したり、同じメッセージを受信したり、まったく異なる何かを実行したりできます。 プログラムの実行中でも1つのコンポーネントを別のコンポーネントに変更できます。これにより、その動作が中断されることはありません。



ソフトウェアシステムのコンポーネントは、同じコンピューター上にある必要さえありません。 システムは分散化できます。 ネットワークストレージは、 IPFSなどの分散データストレージシステムにデータを配置できます。その結果、ユーザーは特定のマシンの状態に依存せず、データの安全性が確保されます。 このアプローチにより、データは確実に保存され、侵入者から保護されます。



PLOは、一部、ARPANETのアイデアの影響を受け、このプロジェクトの目標の1つは、核攻撃のような攻撃に耐える分散ネットワークを作成することでした。



優れたMOPシステムは、アプリケーションの実行中にホットスワップをサポートするコンポーネントを使用する同様のレベルの安定性によって特徴付けられます。 ユーザーが携帯電話からそれを使用し、トンネルに入ったという事実のためにネットワーク範囲外にある場合、機能を継続できます。 ハリケーンがサーバーが設置されているデータセンターのいずれかの電源を遮断した場合も、機能し続けます。



ソフトウェアの世界が、失敗したクラスベースの継承実験から自由になり、OOPの最前線にあった数学的および科学的原則を採用する時です。



開発者は、MOPと関数型プログラミングの調和のとれた組み合わせを使用して、より柔軟で安定した美しいプログラムを作成するときが来ました。

ところで、「MOP」という頭字語はすでに使用されており、「指向プログラミングの監視」を説明していますが、この概念は、OOPとは異なり、静かに消えてしまいます。



したがって、「MOP」という用語がプログラマの専門用語の単語のように見えない場合は、落胆しないでください。 上記のMOP原則に従って、OOPを整頓してください。