「フラットな」オブジェクトモデルまたは「シンタックスシュガー」の価値

過去15〜20年で、信じられないほどの数の新しいプログラミング言語が登場しました。 それらの多くは、「真の」オブジェクト指向言語、または少なくともオブジェクト指向プログラミング（OOP）をサポートする言語として提示されています。 いずれにせよ、これらの言語では、オブジェクト指向の方法論に従って開発を行うことが可能であることが特に強調されています。 プログラミング言語がOOP言語であるためには、 オブジェクトモデルを実装する必要があります。 OOPがプログラミングの形式から概念と方法論により近いものに変わったという事実により、異なる言語は多かれ少なかれ同じオブジェクトモデルに準拠し始めました。 しかし、さらに、これらの言語はさまざまな構文構造で大きくなりすぎており、その一部はいわゆる「構文シュガー」と呼ばれ、オブジェクトに対して頻繁に実行されるアクションをよりコンパクトに実行できます。

ほとんどのプログラミング言語ではオブジェクトモデルが非常に複雑であるため、「フラットな」 オブジェクトモデルの記述を定義して、可能な限り削除します。

1. 「オブジェクト」タイプの終端記号（用語）が定義されています。 「タイプの終端記号」オブジェクト「」という表現は、言語レベルで表現されたこの用語に対して特別な語彙構成が利用可能であることのみを意味し、割り当てとメソッド呼び出しの2つのみを考慮します。
2. 終端記号「オブジェクト」の値は、いくつかのエンティティへの参照です。その説明については、次の段落で説明します。
3. 操作「=」が定義されています-参照による割り当て。 1つの終端記号（ term1 ）を別の終端記号（ term2 ）に割り当てることは、用語term1からterm2に同じエンティティへのリンクをコピーすることを意味します。
4. 用語の意味であるエンティティには、いくつかのメソッドがあります。 メソッドが呼び出され、字句構造「。」を使用してパラメーターが渡されます。 および「（）」、つまりterm.method(param1, param2)
   
   
   
   。
5. エンティティには、状態を構成する（他の）エンティティの順序付けられていないセットがあります。
6. 特定のメソッドセットと特定の初期状態で他のエンティティを作成できるエンティティが少なくとも1つあります。
7. 1つのエンティティから別のエンティティに状態とメソッドのセットをコピーできるエンティティが少なくとも1つあります。
8. コピー（p。7）中のメソッドと状態要素は、コピー先のエンティティに同じ名前の同じものが存在する場合、置き換えられません。

その説明がパラグラフ1〜8で与えられているオブジェクトモデルには、「フラットオブジェクトモデル」という名前が付けられています。

一般的に、上記で定義されたモデルは大幅に簡素化されています。たとえば、デフォルトでは基本型からの継承は考慮されておらず、各オブジェクトでサポートされている継承メカニズムさえありません-このため、このアクションを他のエンティティで実行できる定義済みエンティティが1つあると想定されています。

偶数オブジェクトモデルは、オブジェクト指向をサポートする言語を呼び出すのに十分です。 OOPの特性評価でよく言及される用語は、それぞれ4、5、6、および7、8項で考慮されるカプセル化、継承、およびポリモーフィズムです。 8。 私はすぐに、この言語のオブジェクトモデルに依存せず、オブジェクトの操作に関連しない他の目的のために一般的なケースで意図されている言語の手段は、 ハックと見なされないという事実に注意を喚起したいと思います 。 たとえば、C ++コンパイラの上に構築されたObjective-Cコンパイラの実装を検討する場合、メインのObjective-Cオブジェクトモデルのハッキングを検討する際に、C ++オブジェクトモデルは考慮されません。 少し前に登場した言語を含め、一部の言語がどのようにハッキングで大きくなりすぎたか、およびこれらのハックがどれほど成功したかについて簡単に説明しましょう。

ハッキングなし

確かに、プログラムを美しく明確に書くことがすでに可能になっているときにハックが必要な理由、さらに、そのような言語のインタープリターは、解釈する必要のある追加の構文構造がないという事実のために、コンパイルの点でよりシンプルで高速であることが判明しました。 上記のフラットオブジェクトモデルは、最小限の構文構造（割り当てとメソッド呼び出し）を前提としています。フラットオブジェクトモデルを操作するための構造を除く、他の構造を含まないクリーンなオブジェクト指向言語を作成すると、非常にシンプルになります。 Smalltalkオブジェクトモデルに非常に近い。 フラットオブジェクトモデル用に指定された2つの構文構造-割り当てとメソッド呼び出し（メッセージの送信）がありますが、いくつかのハックもあります。 まず、文字通り特別なオブジェクト-ブロック、配列、文​​字を作成する方法があります。 しかし、これらは非常にきちんとした便利なハックであり、何もする必要はありません。 もう1つ、Smalltalkにはメタモデルがあります。 奇妙なことに、Smalltalkは子供たちがプログラミングできることを期待して作成されましたが、経験豊富なプログラマでさえSmalltalkメタモデルを理解することはほとんどできません。 Smalltalkにはクラスがあり、クラスは明示的なハックであり、オブジェクト指向モデルはクラスなしで実行できます。 ただし、Smalltalkの場合、クラスとメタクラスはどちらも、特にポイント7と8のタスクを解決するグローバルオブジェクトであるため、Smalltalkのハックは非常に巧妙でソフトで、ほとんど誰もいないため、ほとんどハックではありません。苦情が発生します。

たとえば、通常の意味でのコンストラクターはありません;サブクラスが作成されたときに継承される新しいメソッドがあります。 ただし、継承のための特別な構造もありません。継承元のクラスにサブクラスメッセージを送信するだけです。 また、クラスは、次のすべての機能を備えた単純なグローバルオブジェクトです。

 Object subclass: #Person instanceVariableNames: 'Family Name ' ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、オブジェクトの管理の複雑さ全体は、言語の構文レベルではなく、メタモデルのレベルで表されます。メタモデル自体は、すべてのルールによって、言語のオブジェクトモデルに刻まれています。

Selfは、フラットオブジェクトモデルに非常に近く、メソッド呼び出し（メッセージの送信）に置き換えられる割り当て操作さえないため、この意味で、上記で検討したフラットオブジェクトモデルよりもさらにクリーンです。

必要に応じてカーキ

多くのプログラミング言語で長い間登場してきた古いハックは、クラス、静的メンバー、パブリック、プライベート、保護されたメンバー、コンストラクター、デストラクタです。 これらは非常に馴染みのあるものなので、少数の人（控えめに言っても、「少数の人」）はそれらをハックとして分類します。 しかし、実際には、これらのものがプログラミングに持ち込まれ、さらに簡単ではなく、より視覚的になりました。 さらに、クラスのない静的に型付けされた言語では、同時にオブジェクトの型を構成するため、管理が非常に困難です。 静的に型付けされた言語は、率直に言って、OOPにとって理想的な環境ではありませんが。 一般に、これらは非常に適切なものであり、別のことは驚くべきことです。動的に型付けされた言語にどれほど簡単に定着したかです。 そして、この傾向は、たとえばCoffeeScriptでも続いています。 JavaScriptでよく行われるように、オブジェクトは論理的なハッシュテーブルです。外部ではオブジェクトは単なる順序付けられていないプロパティとメソッドのセットであるため、継承とポリモーフィズムを追加するだけであり、JavaScriptで非常に成功しています。 一般に、プロトタイプベースの言語はフラットなオブジェクトモデルに非常に近く、JavaScriptはこれをよく示しています。 しかし、JavaScriptのような成功した言語に基づいて別の言語（CoffeeScript、クラス）を作成することは、伝統への賛辞のように見えますが、このアプローチは一部の人にとってはより馴染みのあるものです。



クラスと静的メンバーがオブジェクトモデルのハックである理由について、もう少し考えてみましょう。 実際、クラスは他のオブジェクトを作成するグローバルオブジェクトとして機能します。 しかし同時に、クラスはオブジェクトモデル（C ++、Java）の範囲を超えていますが、クラスがオブジェクトモデルのフレームワーク内にあり、オブジェクト自体（Smalltalk、Python）がある場合もあります。 クラスがない場合、同じ目的でグローバルオブジェクトを使用できることがわかります。 多くの人は、おそらく変数のようなグローバルオブジェクトが悪いと言うでしょう。 グローバル変数は悪いですが、クラスとの違いがないため、クラスを置き換える言語のグローバルオブジェクトはそうではありません。 それどころか、クラスではグローバルオブジェクトよりも複雑になることがあります。 例としてJavaを取り上げます。 Javaインタープリターがそのようなクラスがあることを「記憶」し、その静的部分を初期化するには、 Class.forName("** ")



を記述する必要があります。つまり、クラスは環境に認識されているようですが、実際には表示する必要があります明らかに彼は何です。

したがって、静的メンバーは、このようなグローバルオブジェクトの通常の（非静的）メンバーとして簡単に作成することもできます。 しかし、繰り返しますが、これらのタイプのハッキングは非常に正常であり、少なくとも大多数の開発者に認識されています。



ジェネリックは、共通ロジックを共有するクラスを作成する際に静的に型付けされた言語の制限のいくつかを克服できるため、強制的で成功したハックに起因する可能性もあります。 しかし、Genericsが型キャストの単なる置換であり、コンパイル段階での互換性をチェックする場合、C ++テンプレートは別の話です。おそらくこれは静的メタプログラミングを可能にするオブジェクトモデルの最も強力なハックの1つであり、明らかに優れています...使い方を知っています。



非常に興味深い点は、ある言語のオブジェクトモデルの制約がどのように別の言語に移行したかです。 PHPには、Javaモデルと構文的に非常に類似したオブジェクトモデルがあります。 すべてうまくいきますが、それらの間には1つの小さな違いがあります。Javaは静的に型付けされた言語であり、PHPは動的です。 PHPには、関数に渡す引数の型を指定するようなものがあります。 しかし、JavaとPHPでは構文的には同じように見えますが、これらの言語は異なるタイプのタイプを持っているため、この引数のタイプの表示はまったく異なる役割を果たします。 Javaでは、コンパイル時に引数をどう処理するかをコンパイラに指示し、PHPでは、Reflectionを使用します。つまり、引数にそのようなスーパータイプがあることを実行時チェックします。

きちんとしたハック

もちろん、まず最初に、きちんとしたハックのカテゴリに、オーバーライド/オーバーロード演算子を含めたいと思います。 これはもはや強制的なハックではなく、オブジェクトモデルの非常に便利な拡張機能です。 すべての演算子のオーバーロードはメソッド呼び出しによって完全に明確に置き換えることができますが、その使用のおかげで、コードはより自然で表現力豊かになります。 これらの種類の機能は、オブジェクトモデルの拡張の成功に起因する場合もあります。

強力なハック

もちろん、最も強力なハッキングの1つはロックです。 カレーは、閉鎖の有無にかかわらず行うことができます。 一般に、関数型プログラミング（FP）は最高レベルのプログラマーの所有物ではなくなり、使い慣れた言語になりました。 しかし、問題はFPが一般的な言語だけでなく、OOPが既に操作している言語にもなったことであり、これは一般に少し異なります。 AFがOOPを移動できなかったことは明らかであるため、AFは上からOOPの上に横たわる以外に選択肢がありませんでした（良い意味で、そうでないと言う方法がわかりません）。 外向きに、構文的には、クロージャーはクールに見えますが、FPは本当に「正直に」機能しているようです。 しかし、賢明な判断で、FPは、たとえばオブジェクトがクラスから関数やモジュールに至るまですべてを占めていたPythonで、どのように正直に機能するのでしょうか？ 正しく、いずれにせよ、動作するのはOPではなく、これらすべてのラッパー、ラムダ、デコレータがインタープリターによって変換されるOOPです。 つまり、FPの世界からのこれらのローションはすべて、OOPに対する定期的なハッキングにすぎないことがわかります。 それらは何に変換されますか？ C＃などの非常に特殊化されたオブジェクト、スーパータイプDelegate



を持つオブジェクト。 これらのオブジェクトは、本質的にクロージャーが実装される1つのメソッドのみを再定義します。 しかし、代理人がいない場合はどうでしょうか？ C＃について話すと、Javaで可能なように、周囲のオブジェクトのコンテキストにロックする可能性のある非静的な内部クラスがないため、この場合は少しストレスがあります。 ただし、大惨事にはなりません。デリゲートオブジェクトを明示的に作成するときに、拡張可能なオブジェクトへのリンクを渡すだけで済みます。

 class SomeContext { public int number { private set; get; } public SomeContext(int initialNumber) { number = initialNumber; } public Addition addition { get { return new Addition(this); } } public class Addition { //      Addition public Addition(SomeContext context) { _contest = context; } public void add(int number) { _contest.number += number; //   private-,      } private SomeContext _contest; } } class Program { static void Main(string[] args) { SomeContext context = new SomeContext(9); SomeContext.Addition addToContext = context.addition; //      addToContext.add(6); Console.WriteLine(context.number); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、デリゲートを使用すると、これはより簡単になります。

 class SomeContext { public int number { private set; get; } public SomeContext(int initialNumber) { number = initialNumber; } public Addition addition { get { return delegate(int what) { number += what; }; } } public delegate void Addition(int number); } class Program { static void Main(string[] args) { SomeContext context = new SomeContext(9); SomeContext.Addition addToContext = context.addition; // external delegate logic addToContext(6); Console.WriteLine(context.number); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どちらの場合でも、別個のロジックが割り当てられているオブジェクト（ Addition



型のオブジェクト）は、 SomeContext



型の拡張可能なオブジェクトの内部コンテキストに対して閉じられていることがSomeContext



ます。 そして、割り当てられたロジックは非常に重要であり、このロジックの処理は別のオブジェクトに委任されます。 ただし、これら2つのソリューションの最初の方法には、存在する場合、その状態を選択したオブジェクトに保存できるという利点があり、2番目の場合、状態を保存せずにDelegate型のオブジェクトが作成されます。つまり、デリゲートの呼び出し間では、現在の状態は保存されません。 ラムダ式を使用してさらに簡潔に記述することもできますが、今ではそれについてではありません。 クロージャーはそれほど強力なものではありませんが、単純なケースでは非常に簡潔に見える場合があります。

ハックのハック

均一なオブジェクトモデルのハックは便利で便利です。 しかし、場合によってはそれらの多くがあり、印象はそれらがもはや管理可能ではないということです。 確かに最もハッキングされたC＃言語の1つ。 クリエイターはこの言語に可能なすべてを押し込みたいと思っていたようで、さらに同じことを複数回押し込もうとしたようです。 特に、これにより、たとえば、同じコールバック構成を定義する4つの異なる方法があります。 何かがやり過ぎだと思われます...しかし、これらの構造はすべて言語の構文を使用するため、それをオーバーロードします。 また、Microsoftの社員がC＃言語オブジェクトモデルをハッキングすることを決定したことについて、他にも多くの奇妙な点があります。

1. 2つのタイプのオブジェクト-参照と値による。 それらの間の明示的暗黙的遷移（パッキング/アンパッキング）。 「値による」オブジェクトは、フラットだけでなく、ある程度馴染みのあるオブジェクトモデルにとってもあまり特徴的ではありません。 そして、これは、「値による」を含むすべてのオブジェクトが、参照であるオブジェクトを継承するという事実にもかかわらずです。 奇妙ですね。
2. 非仮想メソッド。 一般的に言えば、非仮想メソッドは無効化されたポリモーフィズムです。つまり、ルールから抜け出すための方法であり、よく知られているオブジェクトモデルの方法です。 しかし、これはまだ最も奇妙なことではありません。 非仮想メソッドを持つクラスは、インターフェースを実装できます。 つまり、第1レベルでは、インターフェイスから非仮想メソッドを使用する実装クラスに移行すると、ポリモーフィズム自体がこの第1レベルで機能し、その後停止します。
3. メソッドをnew
   
   
   
   として宣言することにより、多相関係を継承階層の任意のレベルで停止できます。
4. 定義上、仮想関数を含めることができない構造体は、インターフェイスを実装できます。 構造では、非常に興味深いことがわかりました。 構造は値型であり、インターフェースはオブジェクト（参照）型です。 SomeStructure
   
   
   
   構造体がSomeInterface
   
   
   
   インターフェイスを実装するSomeInterface
   
   
   
   ます。 SomeStructure
   
   
   
   型のインスタンス構造の既製のインスタンスがあります。 変数SomeInterface anObject = instance
   
   
   
   。 質問に注意してください：anObjectはインスタンス構造のインスタンスを値または参照で参照しますか？ インターフェースはオブジェクト（参照）タイプですが、値によって判明します。 つまり、この割り当てでは、構造インスタンスのコピーが作成され、参照により存在します。 前もってこれを知らなければ、どこかで捕まることができます。

もちろん、これらのすべてのハッキングは重要ではありません。少なくともC＃では、ハッキングされたモデルのサブセットとして多少なりとも通常のオブジェクトモデルがあり、通常のモデルに固執することができます。

結論

洗練された構文は、必ずしもアプリケーションロジックの実装において本当に素晴らしい機会を提供するとは限りません。 ほとんどの場合、「常に」と言わない限り、あらゆる種類の「構文的なお菓子」をオブジェクトの通常の挿入に置き換えることができ、オブジェクトモデルのフレームワーク内であっても、読みにくいコードや構造の悪いコードを使わずに複雑なものを書くことができます。 さらに言えば、かなり単純なオブジェクトモデルを自由に使用でき、 銀色の弾丸にとらわれない恐ろしい獣に優雅かつ単純に対処できます。たとえば、2つのフラグメントを比較するときにわかるように、自明でないロジックを実装する自由度がさらにありますC＃コード。新しいクラスとデリゲートに基づいたソリューションを使用します。 ソリューションがクラスに基づいている場合、ロジックがレンダリングされるオブジェクト（デリゲート）の呼び出し間で状態を維持できます。

引き出せるもう1つの結論は、オブジェクトモデルの機能は、メタモデルに入れると向上する可能性がありますが、言語の構文のレベルでは存在しないということです。 Smalltalkメタモデルは例として提供されました。 この場合、以下の機能が得られますが、構文が「乱雑」になりません。 しかし、実際には、逆の傾向が最近観察されています-プログラミング言語は構文の複雑さを増す方向に開発されており（C＃、CoffeScript、Scala）、純粋なオブジェクトモデルを備えた言語は徐々に忘却に向かっています。 たとえば、自己開発は完全に中止され、Smalltalkはかろうじて生きています。