OOPの専門家に質問です。 - ページ 42 1...353637383940414243444546474849...55 新しいコメント Реter Konow 2019.10.06 17:23 #411 Artyom Trishkin: 明確な分類。 複数のオブジェクトが同じプロパティを持つことを確認したら、これらのプロパティを1つの親オブジェクトに記述するのが論理的です。 子オブジェクトが同名の親オブジェクトのプロパティをオーバーライドする場合、このプロパティは仮想でなければならない。 オブジェクトが異なるクラスからプロパティやメソッドを継承している場合は? 成長し、動的に再構築されるデータ構造(Knowledge Base)を扱う場合、すでに用意されたオブジェクトの「継承素材」を使って、新しいオブジェクトを作成する必要があるのです。この場合、オブジェクトは多重継承により、余分な継承素材を拾って合成されることになる。そのため、正常に機能しません。つまり、多重継承が始まると同時に、退化したオブジェクトに行き着くことになる。それが問題なんだ...。 Artyom Trishkin 2019.10.06 17:30 #412 Реter Konow: オブジェクトが異なるクラスのプロパティやメソッドを継承している場合はどうでしょうか? 成長し、動的に再構築されるデータ構造(知識ベース)を扱う場合、すでに用意されたオブジェクトの「継承素材」を使って、新しいオブジェクトを作成する必要があるのです。この場合、オブジェクトは多重継承により、余分な継承素材を拾って合成されることになる。そのため、正常に機能しません。つまり、多重継承が始まると同時に、退化したオブジェクトに行き着くことになる。それが問題なんだ...。 新しいオブジェクトでは、「残っている」親のプロパティは使わないでください。でも、あなたには何か誤解があるようですね。なぜ、その特性が不要な人のモノを「産む」のか? Nikolai Semko 2019.10.06 17:30 #413 fxsaber: 関連するツールキットが並べられています。作者以外には必要ない。 そして、ニーズもある。しかし、誰もそれを必要としなくなる。 KB、記事などでも同じ状況です。 開発者は、カスタムキャラクター、サービス、ティック、キャッシュ、ピップ、...を導入しています。必要な人がいたとしてもごく一部なので、よくそんなことをしたものだと思います。 テスターの新しいピップスモードを取り上げてみましょう。誰が必要としているのか?-実は誰もいない!?開発者側のテスターのアルゴリズム的な大幅な最適化の構想として生まれました。誰がその有用性を理解していたのか?-誰もいない!そして、すべてにおいてそうです。 今、テスターには大幅な改良が加えられています。しかし、このような改造は誰の役にも立たない。まあ、それを喜ぶオタクはいるんだけどね。現在のMT5-Testerは、どの競合製品よりもクールな仕上がりになっています。しかし、なぜかさらにカッコよくしたいのだそうです。将来の機能はもちろんのこと、現在の機能も誰も評価できない。開発者は、ユーザーより数段頭一つ抜けているのです。そして、テスターの変化の動機は、明らかにマネタイズではなく(誰も理解しないのであれば、単純にありえない)、前例のないことをやりたいという内的な欲求にあります。+ Реter Konow 2019.10.06 17:36 #414 Artyom Trishkin: 新しいオブジェクトでは、「残った」親のプロパティは使用しないでください。しかし、あなたには何か誤解があるようですね。 なぜ、特性が不要なものから「産み出す」のか? 必要だが、完全ではない。新しいオブジェクトは、クラスAの3つのプロパティとクラスBの5つのプロパティ、そして他の3つのクラスの3つのメソッドを使用します。 これらのクラスの残りのプロパティはどうすればいいのでしょうか?どのように彼らから制限するのか? Artyom Trishkin 2019.10.06 17:48 #415 Реter Konow: 必要だが、完全ではない。新しいオブジェクトは、クラスAの3つのプロパティ、クラスBの5つのプロパティ、および他の3つのクラスの3つのメソッドを使用します。 これらのクラスの残りのプロパティはどうすればいいのでしょうか?どのように彼らから制限するのか? クラスAの3つのプロパティをオブジェクトにパッケージ化する。それを受け継ぐ。あるいは、継承せず、3つのプロパティを持つオブジェクトを必要なオブジェクトのプロパティとすることもできます。循環系という、複数のオブジェクトを持つオブジェクトがあります。循環器系の一部として心臓のオブジェがあります。新しいオブジェクトで心臓が必要な場合は、循環器系ではなく、心臓のオブジェクトを継承する。 Andrey Barinov 2019.10.06 17:55 #416 Artyom Trishkin: 循環器系という、多くの対象を持つ物体がある。循環器系の一部として心臓のオブジェがあります。 新しいオブジェクトで心臓が必要な場合は、循環器系ではなく、心臓のオブジェクトを継承する。 新しいオブジェクトがハートを必要とする場合、ハートを継承する必要はありません。心臓は、新しいオブジェクトの一部として、メンバーとして作られるべきです。 新しいオブジェクトが祖先オブジェクトである場合、継承する。そして、新しいオブジェクトが他とWITHしている場合は包含を使用します。 Реter Konow 2019.10.06 18:00 #417 Artyom Trishkin: クラスAの3つのプロパティを1つのオブジェクトに詰め込む。それを受け継ぐ。あるいは、継承せずに、3つのプロパティを持つオブジェクトを、必要なオブジェクトのプロパティにすることもできます。 3つのプロパティをオブジェクトに結合して、新しいオブジェクトのプロパティにする?それは考えものですね...。 しかし、長い鎖を何本も使って遺伝させると、どの段階でも同じような問題が発生します。継承の連鎖が長く、多様であればあるほど、最終世代のオブジェクトはプロパティやメソッドの「混在」が進み、ベースオブジェクトへの個々の連鎖を導き出すことが困難になる。 継承されない場合 - ベースオブジェクトへのアクセスはできません。継承された場合、オブジェクトの複数の「親」によって、ベースオブジェクトへの直接的な連鎖を追跡することができなくなる。 自身のプロパティやメソッドを他のクラスから分離することがますます難しくなっています。 Andrey Barinov 2019.10.06 18:02 #418 Реter Konow: 3つのプロパティをオブジェクトに結合して、新しいオブジェクトのプロパティにする?それは考えものですね...。 しかし、長い鎖を何本も使って遺伝させると、どの段階でも同じような問題が発生します。継承の連鎖が長く、多様であればあるほど、最終世代のオブジェクトはプロパティやメソッドの「混在」が進み、ベースオブジェクトへの個々の連鎖を導き出すことが困難になる。 継承されない場合 - ベースオブジェクトへのアクセスはできません。継承された場合、オブジェクトの複数の「親」によって、ベースオブジェクトへの直接的な連鎖を追跡することができなくなる。 他のクラスから独自のプロパティやメソッドを抽出することが難しくなってきます。 ピーター、私はあなたを強く推薦します https://en.wikipedia.org/wiki/Code_Complete Code Complete - Wikipedia en.wikipedia.org Code Complete Artyom Trishkin 2019.10.06 18:06 #419 Andrey Barinov: 新しいオブジェクトにハートが必要な場合は、ハートを継承する必要はありません。ハートは新しいオブジェクトの一部とし、メンバーのようにする必要があります。 新しいオブジェクトが祖先オブジェクトである場合は継承する。また、新しいオブジェクトが別のオブジェクトを含む場合は、インクルージョンを使用します。 そういう意味じゃないんです。わかるでしょ?親のプロパティを持つモディファイドハートが欲しい場合。 Artyom Trishkin 2019.10.06 18:08 #420 Реter Konow: 3つのプロパティをオブジェクトに結合して、新しいオブジェクトのプロパティにする?それは考えものですね...。 しかし、長い鎖を何本も使って遺伝させると、どの段階でも同じような問題が発生します。継承の連鎖が長く、多様であればあるほど、最終世代のオブジェクトはプロパティやメソッドの「混在」が進み、ベースオブジェクトへの個々の連鎖を導き出すことが困難になる。 継承されない場合 - ベースオブジェクトへのアクセスはできません。継承された場合、オブジェクトの複数の「親」によって、ベースオブジェクトへの直接的な連鎖を追跡することができなくなる。 自身のプロパティやメソッドを他のクラスから分離することがますます難しくなっています。 ピーターだから、心ない相続はダメだと言っているんです。明確な区分と分類。 1...353637383940414243444546474849...55 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
明確な分類。 複数のオブジェクトが同じプロパティを持つことを確認したら、これらのプロパティを1つの親オブジェクトに記述するのが論理的です。
オブジェクトが異なるクラスからプロパティやメソッドを継承している場合は?
成長し、動的に再構築されるデータ構造(Knowledge Base)を扱う場合、すでに用意されたオブジェクトの「継承素材」を使って、新しいオブジェクトを作成する必要があるのです。この場合、オブジェクトは多重継承により、余分な継承素材を拾って合成されることになる。そのため、正常に機能しません。つまり、多重継承が始まると同時に、退化したオブジェクトに行き着くことになる。それが問題なんだ...。
オブジェクトが異なるクラスのプロパティやメソッドを継承している場合はどうでしょうか?
成長し、動的に再構築されるデータ構造(知識ベース)を扱う場合、すでに用意されたオブジェクトの「継承素材」を使って、新しいオブジェクトを作成する必要があるのです。この場合、オブジェクトは多重継承により、余分な継承素材を拾って合成されることになる。そのため、正常に機能しません。つまり、多重継承が始まると同時に、退化したオブジェクトに行き着くことになる。それが問題なんだ...。
関連するツールキットが並べられています。作者以外には必要ない。
そして、ニーズもある。しかし、誰もそれを必要としなくなる。
KB、記事などでも同じ状況です。
開発者は、カスタムキャラクター、サービス、ティック、キャッシュ、ピップ、...を導入しています。必要な人がいたとしてもごく一部なので、よくそんなことをしたものだと思います。
テスターの新しいピップスモードを取り上げてみましょう。誰が必要としているのか?-実は誰もいない!?開発者側のテスターのアルゴリズム的な大幅な最適化の構想として生まれました。誰がその有用性を理解していたのか?-誰もいない!そして、すべてにおいてそうです。
今、テスターには大幅な改良が加えられています。しかし、このような改造は誰の役にも立たない。まあ、それを喜ぶオタクはいるんだけどね。現在のMT5-Testerは、どの競合製品よりもクールな仕上がりになっています。しかし、なぜかさらにカッコよくしたいのだそうです。将来の機能はもちろんのこと、現在の機能も誰も評価できない。開発者は、ユーザーより数段頭一つ抜けているのです。そして、テスターの変化の動機は、明らかにマネタイズではなく(誰も理解しないのであれば、単純にありえない)、前例のないことをやりたいという内的な欲求にあります。
新しいオブジェクトでは、「残った」親のプロパティは使用しないでください。しかし、あなたには何か誤解があるようですね。 なぜ、特性が不要なものから「産み出す」のか?
必要だが、完全ではない。新しいオブジェクトは、クラスAの3つのプロパティとクラスBの5つのプロパティ、そして他の3つのクラスの3つのメソッドを使用します。
これらのクラスの残りのプロパティはどうすればいいのでしょうか?どのように彼らから制限するのか?
必要だが、完全ではない。新しいオブジェクトは、クラスAの3つのプロパティ、クラスBの5つのプロパティ、および他の3つのクラスの3つのメソッドを使用します。
これらのクラスの残りのプロパティはどうすればいいのでしょうか?どのように彼らから制限するのか?
新しいオブジェクトがハートを必要とする場合、ハートを継承する必要はありません。心臓は、新しいオブジェクトの一部として、メンバーとして作られるべきです。
新しいオブジェクトが祖先オブジェクトである場合、継承する。そして、新しいオブジェクトが他とWITHしている場合は包含を使用します。
クラスAの3つのプロパティを1つのオブジェクトに詰め込む。それを受け継ぐ。あるいは、継承せずに、3つのプロパティを持つオブジェクトを、必要なオブジェクトのプロパティにすることもできます。
3つのプロパティをオブジェクトに結合して、新しいオブジェクトのプロパティにする?それは考えものですね...。
しかし、長い鎖を何本も使って遺伝させると、どの段階でも同じような問題が発生します。継承の連鎖が長く、多様であればあるほど、最終世代のオブジェクトはプロパティやメソッドの「混在」が進み、ベースオブジェクトへの個々の連鎖を導き出すことが困難になる。
継承されない場合 - ベースオブジェクトへのアクセスはできません。継承された場合、オブジェクトの複数の「親」によって、ベースオブジェクトへの直接的な連鎖を追跡することができなくなる。
自身のプロパティやメソッドを他のクラスから分離することがますます難しくなっています。
3つのプロパティをオブジェクトに結合して、新しいオブジェクトのプロパティにする?それは考えものですね...。
しかし、長い鎖を何本も使って遺伝させると、どの段階でも同じような問題が発生します。継承の連鎖が長く、多様であればあるほど、最終世代のオブジェクトはプロパティやメソッドの「混在」が進み、ベースオブジェクトへの個々の連鎖を導き出すことが困難になる。
継承されない場合 - ベースオブジェクトへのアクセスはできません。継承された場合、オブジェクトの複数の「親」によって、ベースオブジェクトへの直接的な連鎖を追跡することができなくなる。
他のクラスから独自のプロパティやメソッドを抽出することが難しくなってきます。
ピーター、私はあなたを強く推薦します
https://en.wikipedia.org/wiki/Code_Complete
新しいオブジェクトにハートが必要な場合は、ハートを継承する必要はありません。ハートは新しいオブジェクトの一部とし、メンバーのようにする必要があります。
新しいオブジェクトが祖先オブジェクトである場合は継承する。また、新しいオブジェクトが別のオブジェクトを含む場合は、インクルージョンを使用します。
3つのプロパティをオブジェクトに結合して、新しいオブジェクトのプロパティにする?それは考えものですね...。
しかし、長い鎖を何本も使って遺伝させると、どの段階でも同じような問題が発生します。継承の連鎖が長く、多様であればあるほど、最終世代のオブジェクトはプロパティやメソッドの「混在」が進み、ベースオブジェクトへの個々の連鎖を導き出すことが困難になる。
継承されない場合 - ベースオブジェクトへのアクセスはできません。継承された場合、オブジェクトの複数の「親」によって、ベースオブジェクトへの直接的な連鎖を追跡することができなくなる。
自身のプロパティやメソッドを他のクラスから分離することがますます難しくなっています。