OOPの専門家に質問です。 - ページ 3 12345678910...55 新しいコメント Реter Konow 2019.08.25 10:27 #21 Artyom Trishkin: クリーチャーです。 植物相／動物相 亜種 種 類 ファミリー その他 それがあなたの望みですか？ まあ、ベースとなるエンティティ「Entity」を単純に継承しているだけなんですけどね。 しかし、それよりももっと深く、単細胞／多細胞があり、それが生物への全てです。しかし、生きていないものもある。すべてはタスクに依存し、そのためにベースオブジェクトのプロパティを見つけ、それを継承する必要があります。 本当に気が狂いそうなら、原子に到達して、根本的な親物質を求めて原子を分割し始めることもできる（注意：核分裂反応は連鎖反応になり、世界の半分を破壊することになる）:)。 そうですね。一見すると、OOPのコンセプトは階層を構築するのに適しているように見えます。しかし、OOPによって構築された階層をどのように扱うか？クラスとその内容へのアクセス権があるため、リンク間の遷移が複雑で、構文の海と化しているのです。クラス分けの結果として、ここからオーバーヘッドが始まるのです。OOPは階層を作ることができる反面、それを扱うのが非常に難しくなります。 Artyom Trishkin 2019.08.25 10:56 #22 Реter Konow: そうですね。一見すると、OOPのコンセプトは、階層を構築するのに適している。しかし、OOPによって構築された階層をどのように扱うのでしょうか？クラスとその内容へのアクセス権があるため、リンク間の遷移が複雑で、構文の海と化しているのです。クラス分けの結果として、ここからオーバーヘッドが始まるのです。 OOPは、一方では階層を作ることができますが、他方ではそれを使って作業することが非常に難しくなっています。 そうですね、違いますね。OOPでは、階層のどのメンバーにも、どの場所でも非常に簡単にアクセスすることができます。 まず、必要最小限のプロパティを持つベースオブジェクトを見つけることから始めます。 残りのオブジェクトはそれを継承しています。車輪の再発明を避けるために、ベースオブジェクトは標準ライブラリの CObject クラスを 継承する必要があります。これにより、リストを再発明することなく、独自のオブジェクトの階層を作成することができます CObject --> CBaseObject --> 自分の階層。 CBaseObjectでは、このオブジェクトを返す仮想メソッドを用意する必要があります。そうすると、子孫のそれぞれがこのメソッドを適宜持つことになり、まさに子孫のオブジェクトを返すことになります。CObjectの基底クラスには、すでにType() というメソッドがあります。CBaseObjectの同じ仮想メソッドがあり、それがオブジェクトの型を返してくれれば、どのオブジェクトにアクセスしたのかがわかる。 すべてのオブジェクトの基本的な土台のようなものです。そして、それらはすべて独自のリストに格納されるべきです。各リストには、魚、動物、人間、神など、ある種のオブジェクトだけが格納されます。 つまり、サブタイプごとにリストを用意する必要があります。そして、次のリストを階層的に含む1つのリストが必要です。これらのリストは、それぞれ次の階層のリストも持っている必要があります（繰り返します）。といった具合に。 つまり、ベースとなるリストオブジェクトも必要で、その中に必要なリストを配置します。そして、このベースリストにはType()メソッドが必要で、そこに格納されている任意のオブジェクトをインデックスで返すことができるメソッドが必要です。そして、これが実行されれば、必要なオブジェクトを返すメソッドが、いずれかのリストに自動的に用意されることになります。 一般的には、まず基礎となるオブジェクトを考え、次にリストオブジェクトを考える必要があります。オブジェクトリストも作成する必要はなく、すでに存在して います。 あとは、テクニックの問題ですね。そして、探しているオブジェクトの種類さえわかればいいのです。その階層には多くの種類があるだろうし、その一つひとつが知られていて、リクエストして受け取ることができる。 Georgiy Merts 2019.08.25 11:14 #23 この場合、OOPとは関係ないように思えたのですが、どうでしょうか？ Peterの場合、配列の中のすべてのオブジェクトが何らかのキーで検索されます。 そして、クラスを使っても、配列を使っても、宣言されたオブジェクトの束を使っても、全く違いはありません。 OOPでは、オブジェクトのリストが あり、それぞれがGetColor()メソッドを持ち、ユーザーは正しい色を探すためにすべてのオブジェクトを通過することができます。しかし、OOP を使用しない場合、同じ構造の配列があり、ユーザーは必要な場所から色を取得するためにそれを知る必要がありますが、OOP を使用すると、ユーザーは色がどこにどのように格納されているかを正確に知る必要はありません。 つまり、OOPの場合、ユーザーはオブジェクトの色がどこにどのように保存されているかを知る必要はないのです。そこで、突然、点字で色を表現する「視覚障害者用オブジェクト」を追加する必要が生じた場合、このオブジェクトをリストに追加し、GetColor()メソッドだけを変更すれば、点字の色コードを受け取り、それを通常の形で返せるようになります。私たちのリストのユーザーにとっては、何も変わることはありません。 配列だけだと、そこに「点字」を入れることはできません。そのような分野は入っていません。 Georgiy Merts 2019.08.25 11:16 #24 CObjectを継承してオブジェクトの配列CArrayObjを作り、比較関数だけを書けば、すぐにソートや二項検索ができるようになるのは、OOPの利点がよく表れていますね。 大雑把に言うと、上の例では、色について - OOPの場合 - 比較関数を書いて、GetColor()で色を取得し、色でオブジェクトをソートすることができます。そして、新しい色分けをしたオブジェクトを追加したい場合、やはりGetColor()関数を書いて、その色表現を標準のものにするだけで、すでに書かれているソートや 検索のアルゴリズムが 問題なくこの新しいオブジェクトを受け入れてくれるようになります。 つまり、実はOOPによって、まだ書かれていないオブジェクトを、どのように表現し、どのように格納するかを正確に決める前に、ソートと検索のアルゴリズムを持つことができたのです。 Artyom Trishkin 2019.08.25 11:22 #25 Georgiy Merts: CObjectを継承して、オブジェクトの配列CArrayObjを作り、比較関数だけを書けば、高速なソートや二項検索が可能になるという、OOPの利点は実に明快です。 ピーターに提案されたデータ保存の概念を理解したら、そのことを伝えたいと思ったのです。 Igor Makanu 2019.08.25 11:42 #26 Реter Konow: クラスやその内容へのアクセス権があるため、構文の海やリンク間の遷移に難があるのです。クラス分けの結果、ここからオーバーヘッドが始まる。 OOPは、一方では階層を構築できるのですが、他方ではそれを非常に難しくしています。 アクセス権修飾子により、コンパイル時にエラーを検出可能 一般的に、すべてのこれは、クラスとの仕事を複雑にしない、それを使用しないでください、公共の場ですべてを書き込む。といった具合に、仕事がしやすくなります。 SZZY：OOP、カプセル化、継承など、素敵なフレーズがたくさん......。しかし、他のプログラミングスタイルと比べた場合、OOPの最も重要な利点は、すべてのデータ（クラスフィールド）とこれらのデータを扱う機能（クラスメソッド）を一つの場所（クラス）に格納することである - 本で言えばカプセル化である。さらに、OOPの使用は タスクに依存します。タスクがクラスを拡張することができる場合、階層が必要となり、ベースクラスとその子孫が存在します。 Реter Konow 2019.08.25 11:52 #27 Georgiy Merts: アルチョム・トリシキン OOPの概念では、「オブジェクト」は私の「カーネル」よりも広い文脈で提示されていることは認めざるを得ません。しかし、これまでグラフィックを扱ってきただけで、OOPは幅広い業務に使われているのですから、当然といえば当然です。私のオブジェクトの「メニュー」はかなりまばらで、「ラベル」、「要素」、「ウィンドウ」を除けば、おそらく他にあまりないでしょう...。しかし、グラフィカルなインターフェースには、これ以上必要なものはないのです。 しかし、今、「オブジェクト」の概念を拡張し、階層を構築することが問題になっています。単純な2次元のカーネルでは、知識ベースのオブジェクトの種類をすべて受け入れることはできないので、オブジェクトごとに異なるカーネルを作るか、OOPの概念に従うか、どちらかである。 要するに、これは純粋に技術的な問題なのです。どちらが効率的か、どちらが速いか、どちらが読みやすいか、などなど...。 実際、配列に含まれるすべてのオブジェクトをプロパティのリストとして保持することができ、その中には他のオブジェクトを含む他の配列へのポインタが含まれることになります。あるいは、明示的にOOPを使用 することもできます。オブジェクト指向はどちらのアプローチにも必ず存在し、実装の方法が異なるだけです。同じメモリ、同じポインタ、同じオブジェクト、同じ分類。コードの形だけが違う...。 Реter Konow 2019.08.25 11:56 #28 Artyom Trishkin: ピーターに提案されたデータ保存の概念を理解した時に、このことを伝えたいと思いました。 このデータの保存と取り扱いの概念を理解しておこうと思います。 Artyom Trishkin 2019.08.25 11:59 #29 Реter Konow: このデータの保存と取り扱いの概念を理解しておこうと思います。 なるほど。直接会って話すことができるまたはSkypeで、などなど。ただ、その具体的な内容はこのスレッドのテーマとは異なります。ここでは、私が理解するところでは、あくまで一般的な質問です。 Реter Konow 2019.08.25 12:07 #30 Artyom Trishkin: そうですか（苦笑）。直接会って話をすることも可能です。またはSkypeでも構いません。ただ、その具体的な内容はこのスレッドのテーマとは異なります。ここでは、私が理解するところでは、あくまで一般的な質問です。 わかりました、考えておきます。どちらかというと、個人で書きますね。 12345678910...55 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
クリーチャーです。
植物相／動物相
亜種
種 類
ファミリー
その他
それがあなたの望みですか？
まあ、ベースとなるエンティティ「Entity」を単純に継承しているだけなんですけどね。
しかし、それよりももっと深く、単細胞／多細胞があり、それが生物への全てです。しかし、生きていないものもある。すべてはタスクに依存し、そのためにベースオブジェクトのプロパティを見つけ、それを継承する必要があります。
本当に気が狂いそうなら、原子に到達して、根本的な親物質を求めて原子を分割し始めることもできる（注意：核分裂反応は連鎖反応になり、世界の半分を破壊することになる）:)。
そうですね。一見すると、OOPのコンセプトは、階層を構築するのに適している。しかし、OOPによって構築された階層をどのように扱うのでしょうか？クラスとその内容へのアクセス権があるため、リンク間の遷移が複雑で、構文の海と化しているのです。クラス分けの結果として、ここからオーバーヘッドが始まるのです。 OOPは、一方では階層を作ることができますが、他方ではそれを使って作業することが非常に難しくなっています。
そうですね、違いますね。OOPでは、階層のどのメンバーにも、どの場所でも非常に簡単にアクセスすることができます。
まず、必要最小限のプロパティを持つベースオブジェクトを見つけることから始めます。
残りのオブジェクトはそれを継承しています。車輪の再発明を避けるために、ベースオブジェクトは標準ライブラリの CObject クラスを 継承する必要があります。これにより、リストを再発明することなく、独自のオブジェクトの階層を作成することができます
CObject --> CBaseObject --> 自分の階層。
CBaseObjectでは、このオブジェクトを返す仮想メソッドを用意する必要があります。そうすると、子孫のそれぞれがこのメソッドを適宜持つことになり、まさに子孫のオブジェクトを返すことになります。CObjectの基底クラスには、すでにType() というメソッドがあります。CBaseObjectの同じ仮想メソッドがあり、それがオブジェクトの型を返してくれれば、どのオブジェクトにアクセスしたのかがわかる。
すべてのオブジェクトの基本的な土台のようなものです。そして、それらはすべて独自のリストに格納されるべきです。各リストには、魚、動物、人間、神など、ある種のオブジェクトだけが格納されます。
つまり、サブタイプごとにリストを用意する必要があります。そして、次のリストを階層的に含む1つのリストが必要です。これらのリストは、それぞれ次の階層のリストも持っている必要があります（繰り返します）。といった具合に。
つまり、ベースとなるリストオブジェクトも必要で、その中に必要なリストを配置します。そして、このベースリストにはType()メソッドが必要で、そこに格納されている任意のオブジェクトをインデックスで返すことができるメソッドが必要です。そして、これが実行されれば、必要なオブジェクトを返すメソッドが、いずれかのリストに自動的に用意されることになります。
一般的には、まず基礎となるオブジェクトを考え、次にリストオブジェクトを考える必要があります。オブジェクトリストも作成する必要はなく、すでに存在して います。
あとは、テクニックの問題ですね。そして、探しているオブジェクトの種類さえわかればいいのです。その階層には多くの種類があるだろうし、その一つひとつが知られていて、リクエストして受け取ることができる。
この場合、OOPとは関係ないように思えたのですが、どうでしょうか？
Peterの場合、配列の中のすべてのオブジェクトが何らかのキーで検索されます。 そして、クラスを使っても、配列を使っても、宣言されたオブジェクトの束を使っても、全く違いはありません。
OOPでは、オブジェクトのリストが あり、それぞれがGetColor()メソッドを持ち、ユーザーは正しい色を探すためにすべてのオブジェクトを通過することができます。しかし、OOP を使用しない場合、同じ構造の配列があり、ユーザーは必要な場所から色を取得するためにそれを知る必要がありますが、OOP を使用すると、ユーザーは色がどこにどのように格納されているかを正確に知る必要はありません。
つまり、OOPの場合、ユーザーはオブジェクトの色がどこにどのように保存されているかを知る必要はないのです。そこで、突然、点字で色を表現する「視覚障害者用オブジェクト」を追加する必要が生じた場合、このオブジェクトをリストに追加し、GetColor()メソッドだけを変更すれば、点字の色コードを受け取り、それを通常の形で返せるようになります。私たちのリストのユーザーにとっては、何も変わることはありません。
配列だけだと、そこに「点字」を入れることはできません。そのような分野は入っていません。
CObjectを継承してオブジェクトの配列CArrayObjを作り、比較関数だけを書けば、すぐにソートや二項検索ができるようになるのは、OOPの利点がよく表れていますね。
大雑把に言うと、上の例では、色について - OOPの場合 - 比較関数を書いて、GetColor()で色を取得し、色でオブジェクトをソートすることができます。そして、新しい色分けをしたオブジェクトを追加したい場合、やはりGetColor()関数を書いて、その色表現を標準のものにするだけで、すでに書かれているソートや 検索のアルゴリズムが 問題なくこの新しいオブジェクトを受け入れてくれるようになります。
つまり、実はOOPによって、まだ書かれていないオブジェクトを、どのように表現し、どのように格納するかを正確に決める前に、ソートと検索のアルゴリズムを持つことができたのです。
CObjectを継承して、オブジェクトの配列CArrayObjを作り、比較関数だけを書けば、高速なソートや二項検索が可能になるという、OOPの利点は実に明快です。
クラスやその内容へのアクセス権があるため、構文の海やリンク間の遷移に難があるのです。クラス分けの結果、ここからオーバーヘッドが始まる。 OOPは、一方では階層を構築できるのですが、他方ではそれを非常に難しくしています。
アクセス権修飾子により、コンパイル時にエラーを検出可能
一般的に、すべてのこれは、クラスとの仕事を複雑にしない、それを使用しないでください、公共の場ですべてを書き込む。といった具合に、仕事がしやすくなります。
SZZY：OOP、カプセル化、継承など、素敵なフレーズがたくさん......。しかし、他のプログラミングスタイルと比べた場合、OOPの最も重要な利点は、すべてのデータ（クラスフィールド）とこれらのデータを扱う機能（クラスメソッド）を一つの場所（クラス）に格納することである - 本で言えばカプセル化である。さらに、OOPの使用は タスクに依存します。タスクがクラスを拡張することができる場合、階層が必要となり、ベースクラスとその子孫が存在します。
OOPの概念では、「オブジェクト」は私の「カーネル」よりも広い文脈で提示されていることは認めざるを得ません。しかし、これまでグラフィックを扱ってきただけで、OOPは幅広い業務に使われているのですから、当然といえば当然です。私のオブジェクトの「メニュー」はかなりまばらで、「ラベル」、「要素」、「ウィンドウ」を除けば、おそらく他にあまりないでしょう...。しかし、グラフィカルなインターフェースには、これ以上必要なものはないのです。
しかし、今、「オブジェクト」の概念を拡張し、階層を構築することが問題になっています。単純な2次元のカーネルでは、知識ベースのオブジェクトの種類をすべて受け入れることはできないので、オブジェクトごとに異なるカーネルを作るか、OOPの概念に従うか、どちらかである。
要するに、これは純粋に技術的な問題なのです。どちらが効率的か、どちらが速いか、どちらが読みやすいか、などなど...。
実際、配列に含まれるすべてのオブジェクトをプロパティのリストとして保持することができ、その中には他のオブジェクトを含む他の配列へのポインタが含まれることになります。あるいは、明示的にOOPを使用 することもできます。オブジェクト指向はどちらのアプローチにも必ず存在し、実装の方法が異なるだけです。同じメモリ、同じポインタ、同じオブジェクト、同じ分類。コードの形だけが違う...。
ピーターに提案されたデータ保存の概念を理解した時に、このことを伝えたいと思いました。
このデータの保存と取り扱いの概念を理解しておこうと思います。
そうですか（苦笑）。直接会って話をすることも可能です。またはSkypeでも構いません。ただ、その具体的な内容はこのスレッドのテーマとは異なります。ここでは、私が理解するところでは、あくまで一般的な質問です。