学童のためのEOPです。 - ページ 7 1234567891011121314...18 新しいコメント Dmitry Fedoseev 2019.10.04 14:52 #61 不思議がらないでください、さもないと、ピーター、クラブに入るよう請願しますよ。 カプセル化とOOPの関連性は、2つの関数が1つの共通の変数を扱うときに既に生じています。 Реter Konow 2019.10.04 15:05 #62 Dmitry Fedoseev: 不思議がらないでください、さもないと、ピーター、クラブに入るよう請願しますよ。 カプセル化とOOPの関連性は、2つの関数が1つの共通の変数を扱うときに既に生じています。 いいえ、1つの変数で2つの関数が動作する場合は、グローバルに宣言します。あるいは、片方からもう片方へ渡す。これは、エンティティを多重化する理由にはならない。 また、3つのクラスと2つの構造体にどんなOOPがあるのでしょうか？なぜ、このような短い継承の連鎖が必要なのでしょうか？シンプルな解決策は、複雑な構文とオプションの構文テクニックのセットを取得します。そして、信奉者たちは、OOPの妥当性を正当化するために、機能を潰し始める。ソリューションの観点からは、これは間違っています。 OOPの適用が 正当化されなければならない。 1.学びたいという気持ち。 2.大規模なプログラムやライブラリにソリューションを添付する場合。 3.プログラムの成長と複雑化、データの多様化につながるグローバルな発想。 そうでなく、ソリューションがそれを必要としない場合は、使用する必要はありません。 Dmitry Fedoseev 2019.10.04 15:09 #63 Реter Konow: いいえ、2つの関数が同じ変数を扱う場合は、グローバルに宣言します。どちらか一方から渡す。これは、新しい事業体を作る理由にはならない。 ... まさにYES!コードを同質なものにしないために。 Реter Konow 2019.10.04 15:13 #64 Dmitry Fedoseev: まさにその通りです！（笑コードを同質なものにしないために。 コメントとスタイリストが お手伝いします。 Dmitry Fedoseev 2019.10.04 15:16 #65 Реter Konow: コメントとスタイリストが いれば安心です。 手帳と額のパーマネント・メーキャップも。 Alexey Viktorov 2019.10.05 08:21 #66 これは質問です。 指標計算をクラスとして実装した場合、何らかのメリットがあるのでしょうか？Expert Advisor を作成 する場合、このクラスとライブラリを接続するだけで、インジケータ・ハンドルの呼び出しを回避し、最後のバーで値を受信することができるようになります。 インジケータは、このライブラリを参照して記述することができる。 いかがでしょうか？ Roman 2019.10.05 08:30 #67 Alexey Viktorov: これは質問です。 指標計算をクラスとして実装した場合、何らかのメリットがあるのでしょうか？Expert Advisor を作成 する場合、このクラスとライブラリを接続するだけで、インジケータ・ハンドルの呼び出しを回避し、最後のバーで値を受信することができるようになります。 インジケータは、このライブラリを参照して記述することができる。 いかがでしょうか？ インクルード > インジケーター クラスにインジケーターの例があるので、見てみてください。 削除済み 2019.10.05 08:33 #68 Roman: インクルード > インジケーター そこにあるのは、クラスに関する指標の例です。 事例があるから何？これらの例があるだけでは、@Alexey Viktorovの 提起した疑問には答えられない。 Ihor Herasko 2019.10.05 08:34 #69 Alexey Viktorov: これは質問です。 インジケーターの計算がクラスとしてフォーマットされていれば、何かメリットがあるのでしょうか？ はい、そうします。少なくとも、Expert Advisorとの接続という点では。このインジケータは、コードに一行で含まれています。そして、iCustomは一切必要ありません。 削除済み 2019.10.05 08:35 #70 Ihor Herasko: 必需品です。少なくともEAとの接続という点では。このようなインジケータは、コードに1行で含まれています。また、iCustomでは必要ありません。 例を挙げていただけますか？ 1234567891011121314...18 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
不思議がらないでください、さもないと、ピーター、クラブに入るよう請願しますよ。
カプセル化とOOPの関連性は、2つの関数が1つの共通の変数を扱うときに既に生じています。
不思議がらないでください、さもないと、ピーター、クラブに入るよう請願しますよ。
カプセル化とOOPの関連性は、2つの関数が1つの共通の変数を扱うときに既に生じています。
いいえ、1つの変数で2つの関数が動作する場合は、グローバルに宣言します。あるいは、片方からもう片方へ渡す。これは、エンティティを多重化する理由にはならない。
また、3つのクラスと2つの構造体にどんなOOPがあるのでしょうか？なぜ、このような短い継承の連鎖が必要なのでしょうか？シンプルな解決策は、複雑な構文とオプションの構文テクニックのセットを取得します。そして、信奉者たちは、OOPの妥当性を正当化するために、機能を潰し始める。ソリューションの観点からは、これは間違っています。
OOPの適用が 正当化されなければならない。
1.学びたいという気持ち。
2.大規模なプログラムやライブラリにソリューションを添付する場合。
3.プログラムの成長と複雑化、データの多様化につながるグローバルな発想。
そうでなく、ソリューションがそれを必要としない場合は、使用する必要はありません。
いいえ、2つの関数が同じ変数を扱う場合は、グローバルに宣言します。どちらか一方から渡す。これは、新しい事業体を作る理由にはならない。
...
まさにその通りです！（笑コードを同質なものにしないために。
コメントとスタイリストが いれば安心です。
手帳と額のパーマネント・メーキャップも。
これは質問です。
指標計算をクラスとして実装した場合、何らかのメリットがあるのでしょうか？Expert Advisor を作成 する場合、このクラスとライブラリを接続するだけで、インジケータ・ハンドルの呼び出しを回避し、最後のバーで値を受信することができるようになります。
インジケータは、このライブラリを参照して記述することができる。
いかがでしょうか？
これは質問です。
指標計算をクラスとして実装した場合、何らかのメリットがあるのでしょうか？Expert Advisor を作成 する場合、このクラスとライブラリを接続するだけで、インジケータ・ハンドルの呼び出しを回避し、最後のバーで値を受信することができるようになります。
インジケータは、このライブラリを参照して記述することができる。
いかがでしょうか？
インクルード > インジケーター
クラスにインジケーターの例があるので、見てみてください。
インクルード > インジケーター
そこにあるのは、クラスに関する指標の例です。
事例があるから何？これらの例があるだけでは、@Alexey Viktorovの 提起した疑問には答えられない。
これは質問です。
インジケーターの計算がクラスとしてフォーマットされていれば、何かメリットがあるのでしょうか？
はい、そうします。少なくとも、Expert Advisorとの接続という点では。このインジケータは、コードに一行で含まれています。そして、iCustomは一切必要ありません。
必需品です。少なくともEAとの接続という点では。このようなインジケータは、コードに1行で含まれています。また、iCustomでは必要ありません。
例を挙げていただけますか？