プログラミングでオブジェクトを表現すること。

[Реter Konow]

このトピックは、グローバルな番組制作の問題に心を奪われている人々にとって、興味深いものでしょう。

私が気になっているのは、 「なぜ、よく知られたObjectモデルが標準的なOOPのコンセプトカノンに 含まれているのか」ということです。 " Object "とは、人々がその言葉を発するたびに言葉で表現する存在である、という意味です。プログラミングの登場により、Objectをコードで記述する試みが論理的につながり、そのための特別な技術が発明されたの ですが、ここで「 なぜ 1つだけなのか？まるで、最初の言語が他の言語に完全に取って代わり、進化させなかったかのように。これは古代では不可能なことですが、グローバリズムとプロパガンダの時代には可能です。そして、ある「物体」の表現が世界を制覇し、他のアイデアの方向性を阻むということが起こったのです。

私は（哲学者としての）不満がなければ、とっくの昔に標準的な「物体」の概念を受け入れていたはずです。

1. まず、前置きとして、プログラミングは「オブジェクト」を基本として、どんなプログラムも論理的にオブジェクトに分解されるべきであるという主旨の発言があり、プログラミングの進化が図られた。つまり、アルゴリズム（演算の連続）を書くのではなく、「実体」を作るようになったのです。一方、アルゴリズムは、相互作用の全体的な「アンサンブル」の一部となるように、その構造を入れています。 なぜ？- その方が効率的ですからね。しかし、ここで問題です。「オブジェクト」という哲学的概念は、どこに「公式に登録」されているのでしょうか？しかし、残念なことに、現在も存在しないし、存在し得ない。

これは、OOP概念の作者が、自分たちの哲学的概念の「無謬性」に依存して、恣意的に行動 したことを意味する。

2.以下は、私の主張の一部です。

(1) なぜ標準コンセプトにはツールがないのか " の状態です。"?オブジェクトには状態がないのですか？状態は 構造で記述することもできるが、これでは不便だ。 標準的なコンセプトは、オブジェクトの状態を扱うために設計されているわけではありません。例えば、特殊な構造体を作り、オブジェクトのパラメータをリストアップし、その一部（選択されたパラメータ）をコピーし、この部分をステートと 名付け、あるオブジェクトのステートに対応する値を書き込むのです。そして、それをオブジェクトの主要な構造に接続するのです。

(2)「イベント」という道具は存在しない。つまり、Eventは 標準的な概念では "浮遊 "しますが、列挙、クラス、関数として記述することはできません。プログラミングの事象を簡単に説明できると便利ですね。例えば、構造体として記述し、その中で環境やオブジェクトの「背景」の状態を 指し示し、他の変化の連鎖を開始するトリガーとなる重要な変化を指し示す。 繰り返しになるが、OOPは簡潔なイベント記述のために研ぎ澄まされておらず、名もなく「どこでも」位置する条件の束でそれらを記述するよう提案しているのである。

(3)また、パラメータは 独立したオブジェクトではありません。実際、これはテンプレート化できる最も重要なオブジェクトであり、そのコピーと修正からどんなシステムでも組み立てることができる。そんなことはない...

しかし、私が言いたいのは、「OOPを構築すれば、もっとクールなものを発明できるかもしれない」ということです。また、標準的な概念は物理学や数学ではなく、主観的なビジョンであり、修正することも可能です))。

[Andrei Trukhanovich]

状態というデザイン パターンがあります

傍観者パターンあり

自転車の柄です。

[Igor Makanu]

C# と Delphi の両方がプロパティhttps://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/properties を持っています。

そして、イーウェントは長い間、ギミックではありません。

しかし、私の意見では、むしろ良い曲 "妖精 "の言葉上の別のトピック - YazheVik ... あなたが行くと私は妖精だ！....

[transcendreamer]

一般に、対象を定義するときには主体も定義しなければならず、そうでなければ世界を不完全に記述することになる。

[Dmitry Fedoseev]

ピーター、また違う方角から入ってきた。なぜ、国家はツールでなければならないのか？国家は昔も今も、どこにも存在しない、他の全てよりもさらに原始的なものです。そして、そうです。イベントは状態ではないので、記述されるのではなく、記録されるのです。

[Dmitry Fedoseev]

Реter Konow:

しかし、「オブジェクト」という哲学的概念はどこに あるのでしょうか？残念なことに、今日に至るまで誰も存在しないし、存在し得ないのだ．

なぜなら、それは哲学にまったく基づいていないからです。プログラミングにおけるオブジェクトは、崇高なものでも、神秘的なものでも、あなたが想像しているようなものでもないのです。単純に関数と変数が合体したものです。

[Vladimir]

Реter Konow:

このトピックは、グローバルな番組制作の問題に心を奪われている人々にとって、興味深いものでしょう。

私は、 「なぜ、標準的なOOPの概念で一般的に知られているObjectモデルは、Canon なのだろう？ ".

なぜなら、最初の2つの大きなOが先に来るからです。コンセプトがオブジェクト指向である以上、それらは本質である。手続き型プログラミングのコンセプトであるプロシージャがメインであるのと同様に、SQLではクエリがメインであり、その実行方法などは無視されるのです。カノンではなく、本質を。このフォーラムでは、他のアプローチと対立するOOPの正統化が盛んに行われており、だからこそこのような印象があるのでしょう。

[Aleksey Nikolayev]

自分の自転車を再発明するのではなく、型理論を 勉強し、関数型言語（Haskelなど）でのプログラミングに応用する練習をするのがよいでしょう。

哲学的・論理的な基礎の理解には、バートランド・ラッセルを読むとよいでしょう。

[Koldun Zloy]

Реter Konow:

このトピックは、グローバルな番組制作の問題に心を奪われている人々にとって、興味深いものでしょう。

ぼちぼちと。

これらはすべて、OOPやプログラミングとは関係がない。

針の先にいくつの物体を乗せられるか」と言った方がいい。

[Реter Konow]

Vladimir:

そもそも大文字のOが2つあるから。コンセプトがオブジェクト指向なので、それらが主なエッセンスとなる。手続き型プログラミングの概念でプロシージャがポイントになるのと同じように、SQLではリクエストの実行方法を無視したものがポイントになる、などなど。カノンではなく、本質を。このフォーラムでは、他のアプローチと対立するOOPの正統化が盛んに行われており、だからこそこのような印象があるのでしょう。

私は、「なぜ、オブジェクトの記述や構築のための規格が1つしかないのか」という疑問を投げかけました。

あなたは、私の質問を「なぜOOPはカノンなのか」と決めつけていますね。

プログラミングにおけるオブジェクト指向は、タスクを構造化し、スケーリングし、実装する。それは間違いありません。しかし、なぜフォーマットが同じなのでしょうか？

[Реter Konow]

Dmitry Fedoseev:

なぜなら、それは哲学にまったく依存していないからです。プログラミングにおける対象は、高尚なものでも、神秘的なものでも、その他何でもないのです。単純に関数と変数が合体したものです。

そこで、哲学的なコンセプトがないとダメなんです。オブジェクトのよく考えられた設計図に従わずに、単に関数と変数を結合するだけですか？クラス、構造体、アクセス修飾 子など、私たちには特定のツールが与えられている...。でも、他のツールもありそうだし...。例：状態、サンプリング、マッピング...なんでやねん私が言いたいのは、OOPフォーマットとツールキットはバージョンを持つことができるということです...。

また、場合によっては、別のバージョンのオブジェクト記述形式の方が効果的なこともあります。