私のアプローチコアはエンジンです。 - ページ 138 1...131132133134135136137138139140141142143144145...184 新しいコメント Maxim Kuznetsov 2019.01.11 04:58 #1371 「OOPサポーターの創造力を広げる」、ベレシュチャギン、キャンバス、オイル Реter Konow 2019.01.11 09:45 #1372 皆さん、有益な書き込みをありがとうございます。 今日は、EAとエンジンの間のリソースを介した通信をテストします。ちょうど完成したところです。テスターでも動作するはずです。 Vasiliy Sokolov 2019.01.11 10:03 #1373 Реter Konow:CCanvasクラスで作業しています。開発ではこれ一本です。 クラスはシステムの一部です。ONEであれば、システムは存在しない。 では、なぜクラスオブジェクトを 作り、その機能をOOPルールで参照するのか。 1つのクラスを扱うのに、現実的にはOOPは必要ないのです。しかし、1つのクラスを扱うのに、OOPを使うのですね。OOPは必要ないでしょうけど。ピーター OOPでは、クラスオブジェクトを作ることで、互いに依存しない複数のオブジェクトを扱うことができるんだ。CCanvas で作業する場合、1つのグラフですべてがうまくいくので、OOP はここでは本当に必要ありません。しかし、複数のプロットを異なる領域に表示する必要がある場合、OOPでCCanvasのインスタンスを複数作成しないと難しいです。 あるいは、もうひとつ例を挙げましょう。最近、あるExpert Advisorを修正して、異なるシンボルで同時に取引できるようにしたい（1つのチャート上で動作）、と依頼されました。プロシージャルスタイルでは、異なるシンボルで同時に独立した取引をさせるために、長い時間と複雑な努力が必要だったでしょう。それに対して、私は単純に手続き的なコード全体をクラスに入れて、3つの模範解答を作りました。作業用シンボルなど、それぞれ個別の設定を指定したのですが、一発でちゃんと動きました。このコードは、一回目の試行でそのとおりに動作しました。ユーザーには満足していただけたようです。 あなただってカーネルでOOPを使っているじゃないですか。暗黙の了解でやっているけれども。 レタグ・コノウ根拠がないことにならないように、最後に、まさにその「カーネル」の例を挙げよう。より正確には、ブートファイルである。その中には、いくつかのコアが入っています。 KIB-codeに基づき、自動的に印刷されることを念のためお伝えしておきます。その後、エンジンに搭載。次に、エンジンとの連携です。カーネルは、OOPの用語でいうクラスのインスタンスにあたります。どう呼ぼうと、OOPの要素である。しかし、残念ながら、この要素は自作自演であり、すでに何千人もの未熟な頭脳によって発明され、磨かれてきたものに比べると、構想力において劣っているのです。 Georgiy Merts 2019.01.11 10:12 #1374 何、お前ら、OOPの利点について説得力のあるピーターばかりか？ 説得力がない！もし、あなたが彼のような記憶力を持っていたら、「もっとシンプルに何でもできるのに、どうしてこのOOPはこんなに複雑なんだろう」と思うでしょう。すべての変数をグローバル化し、どこからでも直接アクセスできるようにし、禁止や制限を設けなくしました。 それは、弱った頭では10年前に書いたことを忘れてしまうかもしれない人のためだ。コンパイラと言語が、あらゆる意味でそれを制限することが必要なのである。そして、何年も前のコードで、なぜ、このような構成を書いたのか、その理由を正確に覚えているとき - OOPはカートの5輪目に過ぎないのです。 ピーターの問題は、「OOPか手続き型アプローチか」という選択にあるのではなく、ピーターの問題はターゲット層にあるのです。一方ではプログラミングを得意とし、他方では手を動かすことを好む人が不足していること。私はそのような人たちを観察していません。 Vasiliy Sokolov 2019.01.11 10:13 #1375 Реter Konow:1.その通りです。コンストラクタで指定できる要素の数は限られています。したがって、ダイナミックテーブルは限られた行数で構成され、同時に無制限であることが必要である。解決策は、追加されたパラメータ用に特別な配列を作成し、その値をテーブルのセルでスクロールさせることだけです。 2.はい、コンストラクタは、引用されたコードに基づいてエンジンのカーネルを作成します。+は接続ファイルを表示します。そして、カーネルをエンジン（DRIVE）に乗せました。その後、エンジンは目的のGUIを再生することができます。ペアリングファイルはEAに接続され、EAとのやりとりを開始します。新しいGUIを作るたびに、エンジンに変更を加えなければならないことがわかりました（適切なGUIカーネルを提供する）。これは根本的に間違った解決策だと思います。あなたのエンジンのユーザーが何百人もいると想像してください。しかし、マーケットなどでホストされているエンジンは1つでしかありません。この場合、どうするのでしょうか？各ユーザーが特定のエンジンを配置するために、そのエンジンを自分でダウンロードしなければならないのですか？エンジン用のguiコアはどのように準備するのですか？各ユーザーに個別のエンジンを提供するのでしょうか？- これはすぐに悪夢と化すだろう。つまり、あなたのソリューションはスケーラブルではないのです。 Реter Konow 2019.01.11 10:13 #1376 Vasiliy Sokolov:ピーター OOPでは、クラスオブジェクトを作ることで、互いに依存しない複数のオブジェクトを扱うことができるんだ。CCanvas で作業する場合、1つのグラフですべてがうまくいくので、ここでは本当に OOP は必要ないのです。しかし、複数のプロットを異なる領域に表示する必要がある場合、OOPでCCanvasのインスタンスを複数作成しないと難しいです。 あるいは、もうひとつ例を挙げましょう。最近、あるExpert Advisorを修正して、異なるシンボルで同時に取引できるようにしたい（1つのチャート上で動作）、と依頼されました。プロシージャルスタイルでは、異なるシンボルで同時に独立した取引をさせるために、長い時間と複雑な努力が必要だったでしょう。それに対して、私は単純に手続き的なコード全体をクラスに入れて、3つの模範解答を作りました。作業用シンボルなど、それぞれ個別の設定を指定したのですが、一発でちゃんと動きました。このコードは、一回目の試行でそのとおりに動作しました。ユーザーには満足していただけたようです。 あなただってカーネルでOOPを使っているじゃないですか。暗黙の了解でやっているんだろうけど。 カーネルのそれぞれは、OOP用語でいうところのクラスのインスタンスです。そして、どのように呼ぼうと、それはOOPの要素である。しかし、残念ながら、この要素は自作自演であり、何千もの未体験の頭脳によってすでに発明され、磨かれてきたものにその構想力をゆだねてしまうのです。Vasilyさん、描画機能をクラス化する理由はよくわかりました。なぜなら、それら以外の機能の集合があるからです。 しかし、私の質問は少し違っていた。ニコライは、他のクラスは使わないのに、なぜ、クラスを通して描画関数を呼び出すことを使うのでしょうか？彼は絵を描くだけです。 質問のポイントは、まさにそこでした。 私は、この行為が論理的に無意味であること、そして本人にその自覚がないことを強調しました。 また、解決すべき課題の大きさによって、OOPの使用に 無理が生じることが多いことも強調しました。結局、OOPには枝分かれした分類が必要であり、そのような分類がない場合、わざわざ作る意味があるのでしょうか？ 要は、開発者はツールではなく、仕組みの要件に導かれるべきなのです。 Artyom Trishkin 2019.01.11 10:14 #1377 Vasiliy Sokolov:ピーター OOPでは、クラスオブジェクトを作ることで、互いに依存しない複数のオブジェクトを扱うことができるんだ。CCanvas で作業する場合、1つのグラフですべてがうまくいくので、ここでは本当に OOP は必要ないのです。しかし、複数のプロットを異なる領域に表示する必要がある場合、OOPでCCanvasのインスタンスを複数作成しないと難しいです。 あるいは、もうひとつ例を挙げましょう。最近、あるExpert Advisorを修正して、異なるシンボルで同時に取引できるようにしたい（1つのチャート上で動作）、と依頼されました。プロシージャルスタイルでは、異なるシンボルで同時に独立した取引をさせるために、長い時間と複雑な努力が必要だったでしょう。それに対して、私は単純に手続き的なコード全体をクラスに入れて、3つの模範解答を作りました。作業用シンボルなど、それぞれ個別の設定を指定したのですが、一発でちゃんと動きました。このコードは、一回目の試行でそのとおりに動作しました。ユーザーには満足していただけたようです。 あなただってカーネルでOOPを使っているじゃないですか。暗黙の了解でやっているんだろうけど。 カーネルのそれぞれは、OOP用語でいうところのクラスのインスタンスです。そして、どのように呼ぼうと、それはOOPの要素である。しかし、残念ながら、この要素は自作自演であり、何千人もの無能な頭脳によってすでに発明され、磨かれてきたものにその構想力をゆだねている。時間の無駄です。まず、パースへのアドバイザーとの例は湿布です。彼は専門家を書けないし、何があって何が言いたいのか理解できないし、あなたの非常にわかりやすい例も理解できない。見ての通り、彼は、目をパチクリさせて、ニコライに言ったのと同じことをあなたに言うでしょう。第二に、何千人もの先人の知恵を借りずに、自分のバケツで、これまでのどの解よりも優れた超ユニークなコードを自分で作った、と言って、さらに鼻を高くする口実を与えることになるのです。見てください。それこそ、スライダーを使ったユニークなバケットを配置するのでしょう......。 ZS 厳しいことを言ったかもしれませんが、私は、どうしようもないバカには寛容なんです。 Georgiy Merts 2019.01.11 10:15 #1378 Vasiliy Sokolov:カーネルのそれぞれは、OOP用語でいうところのクラスのインスタンスです。そして、どう呼んでもOOP要素である。しかし、残念ながら、この要素は自作自演であり、何千人もの無能な頭脳によってすでに発明され、磨かれてきたものにその構想力をゆだねている。そうなんですね。それでも、かなりの差があります。私が知る限り、ピーターの店では、この模範的なクラスの店では、ほとんどすべてのものが揃っています。そして、これはOOPのカプセル化パラダイムに適合しない。さらに、グローバル変数 もある。 だからここでは-「OOPの要素」のみ。 Vasilyさん、私がOOPプロジェクトを展開するとき、逆に、「このインターフェースでは、意図されたこと以外は何もできない」と叫ぶ人が出てくると思いますよ(笑)。 Реter Konow 2019.01.11 10:16 #1379 Vasiliy Sokolov:新しいGUIを作るたびに、エンジンに変更を加えなければならないことがわかりました（適切なGUIカーネルを装備する）。これは根本的に間違った解決策だと思います。あなたのエンジンのユーザーが何百人もいると想像してください。しかし、マーケットなどでホストされているエンジンは1つでしかありません。この場合、どうするのでしょうか？各ユーザーが特定のエンジンを配置するために、そのエンジンを自分でダウンロードしなければならないのですか？エンジン用のguiコアはどのように準備するのですか？各ユーザーに個別のエンジンを提供するのでしょうか？- これはすぐに悪夢と化すだろう。つまり、あなたのソリューションはスケーラブルではないのです。いや、ワシリー、君はなんでもかんでも大げさに言うからな（笑)。 デザイナーにボタンがあり、それをクリックすると、すべてのファイルが印刷されます。 そして、エンジンはテキストファイルからカーネルを読み込みます。難しいことではないんです。 Maxim Dmitrievsky 2019.01.11 10:17 #1380 Nikolai Semko: ピーターさんは、OOPの応用について何か誤解しているようですね。申し訳ないが、統合失調症の臭いがする。特殊な意識の形なのだから、進化を止めてはいけない 1...131132133134135136137138139140141142143144145...184 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
「OOPサポーターの創造力を広げる」、ベレシュチャギン、キャンバス、オイル
皆さん、有益な書き込みをありがとうございます。
今日は、EAとエンジンの間のリソースを介した通信をテストします。ちょうど完成したところです。テスターでも動作するはずです。
CCanvasクラスで作業しています。開発ではこれ一本です。
クラスはシステムの一部です。ONEであれば、システムは存在しない。
では、なぜクラスオブジェクトを 作り、その機能をOOPルールで参照するのか。
1つのクラスを扱うのに、現実的にはOOPは必要ないのです。
しかし、1つのクラスを扱うのに、OOPを使うのですね。OOPは必要ないでしょうけど。
ピーター OOPでは、クラスオブジェクトを作ることで、互いに依存しない複数のオブジェクトを扱うことができるんだ。CCanvas で作業する場合、1つのグラフですべてがうまくいくので、OOP はここでは本当に必要ありません。しかし、複数のプロットを異なる領域に表示する必要がある場合、OOPでCCanvasのインスタンスを複数作成しないと難しいです。
あるいは、もうひとつ例を挙げましょう。最近、あるExpert Advisorを修正して、異なるシンボルで同時に取引できるようにしたい（1つのチャート上で動作）、と依頼されました。プロシージャルスタイルでは、異なるシンボルで同時に独立した取引をさせるために、長い時間と複雑な努力が必要だったでしょう。それに対して、私は単純に手続き的なコード全体をクラスに入れて、3つの模範解答を作りました。作業用シンボルなど、それぞれ個別の設定を指定したのですが、一発でちゃんと動きました。このコードは、一回目の試行でそのとおりに動作しました。ユーザーには満足していただけたようです。
あなただってカーネルでOOPを使っているじゃないですか。暗黙の了解でやっているけれども。
根拠がないことにならないように、最後に、まさにその「カーネル」の例を挙げよう。より正確には、ブートファイルである。その中には、いくつかのコアが入っています。
KIB-codeに基づき、自動的に印刷されることを念のためお伝えしておきます。その後、エンジンに搭載。次に、エンジンとの連携です。
カーネルは、OOPの用語でいうクラスのインスタンスにあたります。どう呼ぼうと、OOPの要素である。しかし、残念ながら、この要素は自作自演であり、すでに何千人もの未熟な頭脳によって発明され、磨かれてきたものに比べると、構想力において劣っているのです。
何、お前ら、OOPの利点について説得力のあるピーターばかりか？
説得力がない！もし、あなたが彼のような記憶力を持っていたら、「もっとシンプルに何でもできるのに、どうしてこのOOPはこんなに複雑なんだろう」と思うでしょう。すべての変数をグローバル化し、どこからでも直接アクセスできるようにし、禁止や制限を設けなくしました。
それは、弱った頭では10年前に書いたことを忘れてしまうかもしれない人のためだ。コンパイラと言語が、あらゆる意味でそれを制限することが必要なのである。そして、何年も前のコードで、なぜ、このような構成を書いたのか、その理由を正確に覚えているとき - OOPはカートの5輪目に過ぎないのです。
ピーターの問題は、「OOPか手続き型アプローチか」という選択にあるのではなく、ピーターの問題はターゲット層にあるのです。一方ではプログラミングを得意とし、他方では手を動かすことを好む人が不足していること。私はそのような人たちを観察していません。
1.その通りです。コンストラクタで指定できる要素の数は限られています。したがって、ダイナミックテーブルは限られた行数で構成され、同時に無制限であることが必要である。解決策は、追加されたパラメータ用に特別な配列を作成し、その値をテーブルのセルでスクロールさせることだけです。
2.はい、コンストラクタは、引用されたコードに基づいてエンジンのカーネルを作成します。+は接続ファイルを表示します。そして、カーネルをエンジン（DRIVE）に乗せました。その後、エンジンは目的のGUIを再生することができます。ペアリングファイルはEAに接続され、EAとのやりとりを開始します。
新しいGUIを作るたびに、エンジンに変更を加えなければならないことがわかりました（適切なGUIカーネルを提供する）。これは根本的に間違った解決策だと思います。あなたのエンジンのユーザーが何百人もいると想像してください。しかし、マーケットなどでホストされているエンジンは1つでしかありません。この場合、どうするのでしょうか？各ユーザーが特定のエンジンを配置するために、そのエンジンを自分でダウンロードしなければならないのですか？エンジン用のguiコアはどのように準備するのですか？各ユーザーに個別のエンジンを提供するのでしょうか？- これはすぐに悪夢と化すだろう。つまり、あなたのソリューションはスケーラブルではないのです。
ピーター OOPでは、クラスオブジェクトを作ることで、互いに依存しない複数のオブジェクトを扱うことができるんだ。CCanvas で作業する場合、1つのグラフですべてがうまくいくので、ここでは本当に OOP は必要ないのです。しかし、複数のプロットを異なる領域に表示する必要がある場合、OOPでCCanvasのインスタンスを複数作成しないと難しいです。
あるいは、もうひとつ例を挙げましょう。最近、あるExpert Advisorを修正して、異なるシンボルで同時に取引できるようにしたい（1つのチャート上で動作）、と依頼されました。プロシージャルスタイルでは、異なるシンボルで同時に独立した取引をさせるために、長い時間と複雑な努力が必要だったでしょう。それに対して、私は単純に手続き的なコード全体をクラスに入れて、3つの模範解答を作りました。作業用シンボルなど、それぞれ個別の設定を指定したのですが、一発でちゃんと動きました。このコードは、一回目の試行でそのとおりに動作しました。ユーザーには満足していただけたようです。
あなただってカーネルでOOPを使っているじゃないですか。暗黙の了解でやっているんだろうけど。
カーネルのそれぞれは、OOP用語でいうところのクラスのインスタンスです。そして、どのように呼ぼうと、それはOOPの要素である。しかし、残念ながら、この要素は自作自演であり、何千もの未体験の頭脳によってすでに発明され、磨かれてきたものにその構想力をゆだねてしまうのです。
Vasilyさん、描画機能をクラス化する理由はよくわかりました。なぜなら、それら以外の機能の集合があるからです。
しかし、私の質問は少し違っていた。ニコライは、他のクラスは使わないのに、なぜ、クラスを通して描画関数を呼び出すことを使うのでしょうか？彼は絵を描くだけです。
質問のポイントは、まさにそこでした。
私は、この行為が論理的に無意味であること、そして本人にその自覚がないことを強調しました。
また、解決すべき課題の大きさによって、OOPの使用に 無理が生じることが多いことも強調しました。結局、OOPには枝分かれした分類が必要であり、そのような分類がない場合、わざわざ作る意味があるのでしょうか？
要は、開発者はツールではなく、仕組みの要件に導かれるべきなのです。
ピーター OOPでは、クラスオブジェクトを作ることで、互いに依存しない複数のオブジェクトを扱うことができるんだ。CCanvas で作業する場合、1つのグラフですべてがうまくいくので、ここでは本当に OOP は必要ないのです。しかし、複数のプロットを異なる領域に表示する必要がある場合、OOPでCCanvasのインスタンスを複数作成しないと難しいです。
あるいは、もうひとつ例を挙げましょう。最近、あるExpert Advisorを修正して、異なるシンボルで同時に取引できるようにしたい（1つのチャート上で動作）、と依頼されました。プロシージャルスタイルでは、異なるシンボルで同時に独立した取引をさせるために、長い時間と複雑な努力が必要だったでしょう。それに対して、私は単純に手続き的なコード全体をクラスに入れて、3つの模範解答を作りました。作業用シンボルなど、それぞれ個別の設定を指定したのですが、一発でちゃんと動きました。このコードは、一回目の試行でそのとおりに動作しました。ユーザーには満足していただけたようです。
あなただってカーネルでOOPを使っているじゃないですか。暗黙の了解でやっているんだろうけど。
カーネルのそれぞれは、OOP用語でいうところのクラスのインスタンスです。そして、どのように呼ぼうと、それはOOPの要素である。しかし、残念ながら、この要素は自作自演であり、何千人もの無能な頭脳によってすでに発明され、磨かれてきたものにその構想力をゆだねている。
時間の無駄です。まず、パースへのアドバイザーとの例は湿布です。彼は専門家を書けないし、何があって何が言いたいのか理解できないし、あなたの非常にわかりやすい例も理解できない。見ての通り、彼は、目をパチクリさせて、ニコライに言ったのと同じことをあなたに言うでしょう。第二に、何千人もの先人の知恵を借りずに、自分のバケツで、これまでのどの解よりも優れた超ユニークなコードを自分で作った、と言って、さらに鼻を高くする口実を与えることになるのです。見てください。それこそ、スライダーを使ったユニークなバケットを配置するのでしょう......。
ZS 厳しいことを言ったかもしれませんが、私は、どうしようもないバカには寛容なんです。
カーネルのそれぞれは、OOP用語でいうところのクラスのインスタンスです。そして、どう呼んでもOOP要素である。しかし、残念ながら、この要素は自作自演であり、何千人もの無能な頭脳によってすでに発明され、磨かれてきたものにその構想力をゆだねている。
そうなんですね。それでも、かなりの差があります。私が知る限り、ピーターの店では、この模範的なクラスの店では、ほとんどすべてのものが揃っています。そして、これはOOPのカプセル化パラダイムに適合しない。さらに、グローバル変数 もある。
だからここでは-「OOPの要素」のみ。
Vasilyさん、私がOOPプロジェクトを展開するとき、逆に、「このインターフェースでは、意図されたこと以外は何もできない」と叫ぶ人が出てくると思いますよ(笑)。
新しいGUIを作るたびに、エンジンに変更を加えなければならないことがわかりました（適切なGUIカーネルを装備する）。これは根本的に間違った解決策だと思います。あなたのエンジンのユーザーが何百人もいると想像してください。しかし、マーケットなどでホストされているエンジンは1つでしかありません。この場合、どうするのでしょうか？各ユーザーが特定のエンジンを配置するために、そのエンジンを自分でダウンロードしなければならないのですか？エンジン用のguiコアはどのように準備するのですか？各ユーザーに個別のエンジンを提供するのでしょうか？- これはすぐに悪夢と化すだろう。つまり、あなたのソリューションはスケーラブルではないのです。
いや、ワシリー、君はなんでもかんでも大げさに言うからな（笑)。
デザイナーにボタンがあり、それをクリックすると、すべてのファイルが印刷されます。
そして、エンジンはテキストファイルからカーネルを読み込みます。難しいことではないんです。
ピーターさんは、OOPの応用について何か誤解しているようですね。
特殊な意識の形なのだから、進化を止めてはいけない