OOPの専門家に質問です。 - ページ 25

 
Igor Makanu:

OOPの概念そのものが、ただ書かないということを意味しているのです。

このセリフの代わりに想像してみてください。

クエリや各種チェックを多く行う必要があります。- そのため、自分でライブラリを書いたり、資料を調べたりする時間がかかります

クラス形式で用意されたソリューションのメソッドを1つだけ使うというタスクがあるとします。クラスのインスタンス(オブジェクト)を作成し、用意された Select(const bool select) メソッドを使用します。

そのような操作をしないのであれば、メモリを解放する=オブジェクトを削除する

例えば、ボタンを表示し、それを押すことでマーケットウォッチのシンボルを有効/無効にするタスクがあるとします ---> クラスを作成し、既製のボタンクラスと既製のCSymbolInfoクラスをカプセル化します - タスクは完了です。

OOPパラダイムは、クラスで何ができるかという一般的な情報しか与えません - CSymbolInfoをカプセル化したくない場合は、クラスを継承してください。

信じる、理解しない、受け入れない。これらの注意点をすべてクリアしなければできない具体的なタスクがあるとき、「心の悟り」と「理解」が訪れるのです。しかし、今のところ、私から見ると、ただ派手なガジェットが正義とは限りませんNot alwaysはneverという意味ではない。C tradeクラスを使うのはいいのですが、上に書いたように受け付けないんです。ドキュメントにあるSymbolSelect関数の記述を探すのが大変なら、SBではもう大変です。

イゴール・マカヌ

HH: "on my fingers",OOPの本質は与えられた問題に対して、実装の知識がなくても 素早く解決 できることです。

その場合、実装を知る代わりに、目的のメソッドをどのように呼び出すか、どこにあるかなどを知る必要があります。これはプログラミング言語の中の言語の一種なのでしょうか?

1つのプロジェクトで、1つのオブジェクトのインスタンスを複数持つ必要がある場合は理解できる。しかし、今のところ、前述のArtem氏のデモを除いて、そのような実装を見たことがない。その場合、より良い、より簡単な、よりシンプルなものであることは明らかですが、私は、必要性がない、課題がないため、完全な理解に至りませんでした。mql5の関数を一回使うために、オブジェクトを変更するのは意味がないのです。それが私の推論です。

 
Alexey Viktorov:

その場合、実装を知る代わりに、正しいメソッドをどのように呼び出すのか、どこにあるのかなどを知る必要があります。これはプログラミング言語の中の言語の一種なのでしょうか?

ドキュメントを見ると、公開されているものにはすべてマニュアルがついていて、いわば倫理観

スタイルではなく、パラダイムです。- 概念、礼儀作法、誰もそう書くことを強制されないが、なぜか最も一般的なスタイルである

 
Igor Makanu:

OOPの本質は、実装を知らなくても与えられた課題を素早く解決することにある

データの入った構造体を渡して関数を呼び出すと、その関数の実装を知らなくても同じように高速な解を得ることができるのです。
 
Alexey Navoykov:
ある関数を呼び出し、そこにデータの入った構造体を渡すと、その関数の実装を知らなくても同じように高速な解を得ることができます。

はい、しかし、あなたの方法は、この上に制限されます、OOPであなたも継承することができます - たとえ実装を知らなくても、あなたのタスクに追加し、頭に浮かぶ最初の事 - 丸みを帯びたエッジのボタン、ウェブ上の例のトンがあります。

SZZ:それに、コンストラクターでオブジェクトを展開するロジックは、かなり便利です。

 
Реter Konow:

クラスは、オブジェクトの記述である。よかったです。オブジェクトのプロパティと機能が含まれる。オッケーです。これらはすべて、命令され、開かれ、あるいは保護されています。

そうすると、OBJECT(オブジェクト)自体が絵から外れてしまいます。それは、授業の中でのことです。その名前と説明の文脈で。つまり、OOPでは、オブジェクトは、まさに属性(プロパティだけでなく、機能的要素であるメソッド)の集合であるが、私が持っているよりも秩序立ててカプセル化されているのである。(その方が理にかなっている)。

Peter: 最後にクラスについて、メモリ割り当てや メソッド呼び出しのコンテキストにおけるクラスのあり方について、つまりコンパイラにとってすべてがどのように変換されるのかについて、ググってみてください。その後、ほとんどの疑問は自ずと解消されるでしょう。
 
Petros Shatakhtsyan:

本を読まないと意味がわからない。せめてVC++を21日以内に。

CDialogをベースにしたWindowsアプリケーションを作成し、様々なオブジェクトを作成し、それらがいかに簡単に管理されるかを確認することをお勧めします。

その後、ベンチャーを捨てることになる。残念ながら。

まあ、それはないでしょう。要は、私のアプローチとOOPの間に概念的な違いはほとんど見出せなかったということです。また、私のアプローチはオブジェクト指向です。 オブジェクトはカーネルにカプセル化され、非常に特殊な表現を持っています。これらはポインタによってリンクされ、エレメント、ウィンドウなどの複合体を形成しています。グラフィックを超えて、もっと多様性を含んだ別の形のカーネルを作れば、OOPでも遜色ないものになるはずです。

アプローチの違いは、コードの書き方、構文、機能の分散方法などです。私のアプローチでは、機能は統合される傾向にあり、OOPでは分割される傾向にあります。機能の統合はシステムの効率化と少ない構文量を保証し、機能の分割はコードの移植性を容易にする。モジュールのプラグインが可能です。一般的には、このような違いがあると言われています。

もちろん、私のアプローチは、まだそのような広い意味での「客観性」を持ってはいません。でも、これをどう解決するかは、すでに考えています。カーネルは単一の型であるため、格納されるプロパティが制限されるが、カーネルは単一の行列である必要はない。コアの複合化も可能です。主な利点は、オブジェクトのデジタル表現であり、長い記述や追加の構文、機能の断片化を必要としないことです。

でも、OOPはとても興味深いですね。見習います(笑)。
 
Vladimir Simakov:
Peter 最後に、クラスについて、メモリ割り当てや メソッド呼び出しのコンテキストでどのようなものか、つまり、コンパイラがすべてを変換するものについて、ググってみてください。その後、ほとんどの疑問は自ずと解消されるでしょう。
オッケーです。ぜひググってみます。
 

OOPという概念には多くの思想が込められていますが、その内容は以下の通りです。

クラス」「オブジェクト」「プロパティ」「カプセル化」「ポリモーフィズム」「継承」といった概念を残して、構文や専門用語を抽象化しよう。その哲学的な "根源 "を説明する。

現実は「空間」「時間」「物質」のプリズムを通して意識によって認識され(これが感覚器官の働き)、「物体」はそれらの連続的な相互作用の離散的な結果である。

相互作用の形態の多様性は、主体の無意識がある「枠組み」に「植え付ける」様々な対象を生み出す。 この枠組みは枝分かれしたカスケード構造を持ち、その「原型」の一つとして無意識に「組み込まれる」。フレームワークは、その構造全体に分散している新しい、新しいオブジェクト(の情報)を取り込みます。 これが、OOPの概念からきているところです。これは、無意識の「アルゴリズム」を模倣した意識的な対象の分配と結合である。 自分の思考の方法をマスターした主体は、その働きを脳の「トレース」機構、つまりコンピュータでシミュレートすることができるようになるのだ。コンピュータが脳の哀れなパロディであっても、人間は客観的世界の影しか認識できない。 カスケード、枝分かれする原型は、一般に我々の記憶内部のオブジェクト、特性、プロセス、すべての情報の分布の「パターン」である。これは、現実の認識を単純化し、私たちを取り巻く世界のモデルを構造化する生物学的な道具であり、自然から与えられたものです。 私たち自身の「自然な」(つまり無意識の)情報処理メカニズムを意識することは、OOPを使う 上で必要な自己認識のレベルなのです。

記憶、学習、知覚を容易にするこの暗黙の、生物学的な、「木のような」原型を、「人工的な」応用という文脈で考えてみましょう。OOPでは、オブジェクトの記述をクラスにカプセル化し、プロパティや値を設定することで「生産」します。 オブジェクトの関係は分類に反映され、プロパティやメソッドをグローバルからプライベートに継承することで実現されます。実際には、次のようになります。すべてのプライベートオブジェクトは単なるオブジェクトであり、したがって、単なるオブジェクトのすべてのプロパティとそのプライベートプロパティを持ちます。派生したオブジェクトは、そのプライベートプロパティを共通プロパティとして持ちますが、そのプライベートプロパティを持つことになります。さらに、チェーンは無限に分岐することができます。これは、オブジェクトのメソッドでも同じです。メソッドは、行動、相互作用、プロセス、状態の変化を反映します。オブジェクトのメソッドは、プロパティのように一般的なものからプライベートなものまで分散されています。一般的なプロセスがあれば、それぞれの離散的な形態が独自の特性を持つことになる。 そして、これがポリモーフィズムである。つまり、オーバーロードとは異なり、ポリモーフィズムは基礎となる関数の仕組みを保持したまま、異なるプライベートな実装を提供します。これが「機能的」継承である。

このように、OOPにおける「ツリー的なもの」はいたるところにあり、どんなスキームを考え出したとしても、「ツリー」を得ることになる)。しかし、これは自分の無意識のうちに情報を扱うパターンをコピーしているだけなので、正しいのです。

 
Реter Konow:

OOPの概念についていろいろ考えていたのですが、これがそれです。

...

タフであること。

ピーター、君は政治に参加する必要がある。このような才能は、ここでは求められていない。巧みに、そしてわかりやすく、何も言わずに、多くを語ることだ。

 
Artyom Trishkin:

...

説明しよう。要するに、OOPは私たちの記憶の中で無意識に行われている情報の分配を再現しているのです。情報はカスケード状に、「ツリー状」に「レイアウト」されています。これは、無意識のアーキタイプ(隠されたメカニズム)によって条件づけられているのです。この仕組みを「感じた」人たちが、プログラミングにうまく応用するようになったのです。OOPは、私たちの無意識と同じ仕組みで、共通の性質や機能を継承の連鎖によって実現する。


意識と無意識の仕組みが分かれば、その仕組みをコンピュータで再現することができるようになります。技術的なことから一歩引いて、コンセプトの根幹を見つめただけです。