「純粋なOO言語」」という用語の正式な定義？
SO兄弟の間で、このような質問をするのにこれ以上の場所は考えられません。もともと私は「pythonは純粋なOO言語ですか？」しかし、用語を定義しようとしているときに問題や人々が経験するある種の不快感を考慮して、用語自体の明確な定義を取得することから始めることにしました。
correspondence で始めるのはどちらかといえば公平です。この用語を作り出したAlan Kay博士は、細胞や他の生物との生物学的類似性にインスピレーションを得ていることに注意してください。
タスクにアプローチするには、次の方法があります。
- （Smalltalk、Scala、
Java、など-可能な例ですが、IMOはこの方法では本当に完全でもなく、 実りの多い ）でもありません。 - 正式な定義を与える（またはそれに近い、たとえばより学術的または数学的なスタイルで）。
- 具体的な言語の意味論的コンテキストまたはアプリオリなプログラミング経験に完全に依存する哲学的定義を与える（コミュニティによる説明が成功する可能性があるはずです）。
現在のバージョン： "特定のプログラミング（ 正式な ）言語で、演算とオペランドを（ 文法的に ）区別でき、この型がオブジェクト（OOPの意味で）であるかどうかに関係なく、各オペランドの型。オブジェクトであるこの言語に少なくとも1つの型がある限り、そのような言語をOO言語と呼びます。最後に、すべての型言語の純粋な（強力な）オブジェクト指向言語であると私たちが定義したオブジェクトでもあります。 "
それの可能な改善をいただければ幸いです。ご覧のとおり、「オブジェクト」という用語に依存するように定義しました（多くの場合、オブジェクトのクラスとして完全に参照されます）。
[編集]
さらに、私は（幸運にもよく理解されている）typeの概念を型付き言語のように使用します。データ型プログラミングまたは型指向プログラミングは、（プログラムテキスト、つまりリテラルおよびデータ変数の特定の値を処理する方法-型安全性に発展するもの）の構文上の解釈であるだけでなく、言語文法に起因し、正式な方法で学習できます。 （数学的論理を使用）いわゆる type systems 。特定の型システムにいわゆる汎用型を要求することは、OO言語の純粋さを定義する方法の1つであることに注意してください（これを意味的に拡張する方法があります） 。
[〜＃〜] nb [〜＃〜]
回答方法：
- 用語や概念の理解をサポート/説明する本やリファレンスを指定すると役立ちます（通常、適切な定義は、初級を除くすべての依存する概念をカバーまたは参照します）。
- 可能であれば、明確でない場合は回答/定義のインデントされたカテゴリを示します（上記を参照：1-言語の例、2-数学的論理、3-技術的な説明とプログラミングの哲学）
- 分類は重要です（また、用語pure-OOが用語OOに含まれているため）一方で、他のよく知られている方法論からOOパラダイムの要素を分離してみてください（そして、決してそれらを混同/重複することはありません。たとえば、通常、 [モジュールプログラミング の要素はOOプログラミングでカバー/具体化できます）：OOPと（含む、またはその一部である）関数型プログラミング、論理プログラミング（特に強く専門化された）、Abstarctデータ型（ADT）、モジュラー、メタプログラミング（ジェネリックとLISPのマクロ展開時間）、コントラクト（たとえばEiffel）、アスペクト指向（AO）、 （宣言的分類と機能的分類の違い、およびダイクストラの構造化された履歴定義の明確性）
正式な定義を与えることの難しさ：驚くほど十分に数学的な説明を与えることは簡単ですOOPは、特定の論理（形式）システムの形式（ほとんどの場合、型ベース）であり、1つの概念を次々に定義します。その形式を タイプセーフチェック または 新しい言語設計の側面 に適用することで、単なる抽象的な エンターテイメント または演習よりも、より実用的なことを試みることもできます（ 直観型理論 、 依存型 のOOPのルックアップ定式化も、独立して、ラムダ計算としてのFOL形式とカテゴリー理論を使用して）。ここでの主なポイントは、驚くべきことではありませんそのような定式化IMOは、OOPの最初の不完全な理解（コンピュータエンジニアリング）によって強く偏り（欠陥）であり、最終的にその後はほとんどアクセスできなくなります（したがって、プログラミングの世界に逆戻りすることはほとんどありません-おそらく特定の割合の発見を除いて 人気のある言語に統合されて、公式の世界から戻ってきたアプリケーション ）。
だから、はい、定義だけでなく、正確に「良い」定義を与えることは困難です。しかし、皆さんの経験と直接的な関与のおかげで、私はここでこれを尋ねることに前向きです。
Alan Kayによると、OOはすべてメッセージパッシングに関するもので、それで終わりです。ポリモーフィズムやカプセル化などの品質は、実際にはメッセージパッシングから派生していることがわかります。
現在、そのスタンスは実際には非常に極端です。なぜなら、それは基本的に、Smalltalkと言語だけが資格を得るということを意味するからです。
OOは、エンティティ上にシステムを構築し、それらの状態を完全にカプセル化し、固有の多形性の性質により交換可能にされると定義できます。したがって、純粋にOO言語は、これら2つのコア品質が常に満たされることを保証します。レンダリングされるOO言語「純粋でない」とは、これらの基準を満たさない構成の作成を可能にするメカニズムです。可能性：
- パブリックフィールドを宣言する
- 特定のクラスとそのサブクラスのインスタンスのみを保持できる変数を宣言します（つまり、変数はインターフェースに対して入力する必要があります。これは、ケイのアノロジーで生物学的オブジェクトが通信するものです）。問題のクラスが最終的な場合、さらに狭くレンダリングされます。ポリモーフィズムの余地がさらに少なくなる
- プリミティブを宣言する
繰り返しになりますが、私見の言語の純粋さは、長所よりも短所です。 OOは特効薬ではありません。単一のパラダイムはありません。
私はこれにOOP構文のみを使用する言語として定義することでアプローチします（純粋なFP言語が不変の純粋な関数を使用するのと同じ方法でデータのみ）。
特に：
- プログラムが操作するすべてのエンティティは最初のクラスのオブジェクトです-つまり、プリミティブ、ポインタ、配列などはありません。
- 唯一のものオブジェクトで実行できるのは、そのオブジェクトで（潜在的に多態性のある）メソッドを呼び出すことです（==メッセージを送信する）。他の操作はありません。
- すべてのデータはカプセル化されています-つまり、パブリックフィールドへのアクセスはありません。オブジェクトのメソッドを経由する必要があります
- ファーストクラスの関数がある場合、それらもオブジェクトでなければなりません-したがって、
functionObject.call(param1,param2)のようなことを行う必要があります - グローバル変数なし-このようなものが必要な場合は、オブジェクトを使用して現在のグローバル環境を表す必要があります。
environment.getValue("myThing")またはクラスオブジェクトに変数を配置
ただし、これでもかなりの数のオプションが開いたままになります。
- クラスベースとプロトタイプベースのオブジェクトモデル
- 継承の実装方法（ある場合）
- メソッドに単一または複数のディスパッチがあるかどうか
- オブジェクトが静的または動的に型付けされているかどうか
- メソッド呼び出しに使用される正確な構文（たとえば、ゲッター/セッターなどの構文糖を使用できます）
いわゆるOO言語についての議論は、常に少しばかり頭を悩ませてきました。すなわち：
「誰かが言語XがOOだと言ったので、言語XはOOと等しいため、言語Xの機能を欠くすべての言語はOOになることはできません。そして、私が自分のコードを言語X、私がするすべてはOOです。」
オブジェクト指向設計という用語は、3つのことに要約されます。
- プログラムの残りの部分についての不必要な情報を知らない自律オブジェクトを備えたモジュール設計、別名 疎結合 として。
- 意図的および偶発的な外部アクセスを防ぐための、オブジェクト内のデータのカプセル化。
- オブジェクト間の明確に指定された依存関係。疎結合を実現するだけでなく、プログラムの保守と拡張を容易にするため。
1）は純粋なプログラム設計であり、任意のプログラミング言語で実現できます。ただし、一部の言語には、クラス/構造体やプライベートキーワードなどの役立つ機能があります。
2）は主にプログラム設計ですが、偶発的な使用から保護するためにプライベート/静的などの言語メカニズムが必要なため、言語サポートなしでは完全に達成することはできません。
3）は主にプログラムの設計です。通常、3つの異なる依存関係があります。「オブジェクトXはオブジェクトYを含む」、「オブジェクトXは一種のY」、「オブジェクトXはオブジェクトYと相互作用する」です。これらの依存関係を支援する多くの言語機能があります：継承/ポリモーフィズム、抽象基本クラスなど。
さて、上記を見ると、OOプログラムを書くための言語機能はほとんど必要ないことがわかります。これらの機能により、はるかに簡単になります。
泥だらけの後方ロジックを使用しても、上記の目標を達成することはできません。classキーワードを使用したからといって、プログラムが自動的にモジュール設計を取得することはありません。継承を使用しているからといって、オブジェクトの依存関係が意味をなすとは限りません。 OO機能を備えた言語でも、class TheWholeBloodyProgramまたは「動物は猫を継承します」。
悲しいことに、優れたオブジェクト指向プログラム設計のトピックは、この種の議論ではほとんど言及されていません。洗脳されたプログラマーは、たとえば「C++にはプリミティブデータ型があるため、C++プログラムはオブジェクト指向ではありません」のような構文とうなり声だけを見て、ヒントを使用せずに、自分の好きな言語でひどい恐ろしいプログラムを書き始めます。プログラム設計はこれまでになく。
質問への回答：ごく少数、適切なOOプログラム設計をサポートする言語がある場合。特定のOO関連の機能を持つ言語を見つけるのは、プログラマーがそうでない限り、無関係です。オブジェクト指向設計の意味を知っている。特定の言語がオブジェクト指向であると主張するプログラマーは、おそらくOO全体の概念を理解していない可能性が高い。希望者に尋ねるOOプログラマーがどのように設計するかOOプログラム。彼らが最初に行うことは、言語のキーワードを叫び始めることである場合、彼らは知らないことを安全に想定できますOOデザイン。
おそらく、生のソースコードのはるか上に、高度な高レベルUMLっぽいツールがいくつか存在するため、プログラマーはオブジェクト指向の優れたデザインのプログラムのみを作成する必要がありますが、私はそれを疑っています。 OOプログラミングに最適な設計ツールは、おそらく人間の脳と常識です。
いいえ、正式な定義や有用な定義はありません。一部の人にとっては、OOPは「ユニバーサル基本クラス」および「ガベージコレクターで最適な参照セマンティクスを使用する必要がある」を意味します-そして、これまで最も関連性の低いものの1つである構文についての問題を取得することもできます発明した。
最終的に、最初に、「オブジェクトとは何ですか？」という質問に答える必要があります。より狭義の人は、無意味なユニバーサル基本クラスから継承し、資格を得るために不必要にガベージコレクターに割り当てられることを主張します。しかし、私ははるかに有用な定義を好みます。 OOPの目的は、いくつかのデータと、そのデータに対して呼び出すことができるいくつかの関数を用意することです。
- オブジェクトはいくつかの状態を保持し、その状態に対していくつかの機能を提供します。
この場合、intでも対象となります。結局のところ、プリミティブまたはオブジェクトのいずれかを受け入れることができるテンプレートコードをC++で作成すると、プリミティブが大幅に異なると主張することが難しくなります。 Vector v1, v2; v1 + v2;の代わりにint v1, v2; v1 + v2;に意味のある違いはありません（容認できない初期化セマンティクスを除いて、1つは認めなければなりません）。また、ラムダなどのオブジェクトが状態（キャプチャ）を保持し、その状態でラムダを呼び出す関数を提供するため、これをオブジェクトにすることができます。
幸いにも、解放された関数へのポインターをオブジェクトとして分類することもできます。どちらの関数も、状態（アドレス）とその状態の関数（それを呼び出す）を保持しているためです。したがって、すべてのフリー関数が実際にはグローバル関数ポインターであると言ったとしても、フリー関数を許可する必要があります。
あなたはそれを否定的な例で考えることができます。 Javaは、オブジェクトではないプリミティブ型もあるため、純粋なオブジェクト指向言語ではありません。これらは整数、倍精度浮動小数点数、配列などです。純粋なオブジェクト言語では、オブジェクトのセマンティクスはすべてに利用できます。
また、オブジェクトフレームワーク内であっても、どの程度の言語が変更に対してクローズされるかという問題もあります。 Javaでは、StringやClassなど、一部のクラスに新しいサブクラスを定義することはできません。
どの言語が純粋ですか？頭に浮かぶのは、Smalltalkだけです。