私のアプローチコアはエンジンです。 - ページ 138

新しいコメント
 

「OOPサポーターの創造力を広げる」、ベレシュチャギン、キャンバス、オイル


 

皆さん、有益な書き込みをありがとうございます。

今日は、EAとエンジンの間のリソースを介した通信をテストします。ちょうど完成したところです。テスターでも動作するはずです。

 
Ре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の要素である。しかし、残念ながら、この要素は自作自演であり、すでに何千人もの未熟な頭脳によって発明され、磨かれてきたものに比べると、構想力において劣っているのです。

 

何、お前ら、OOPの利点について説得力のあるピーターばかりか？

説得力がない！もし、あなたが彼のような記憶力を持っていたら、「もっとシンプルに何でもできるのに、どうしてこのOOPはこんなに複雑なんだろう」と思うでしょう。すべての変数をグローバル化し、どこからでも直接アクセスできるようにし、禁止や制限を設けなくしました。

それは、弱った頭では10年前に書いたことを忘れてしまうかもしれない人のためだ。コンパイラと言語が、あらゆる意味でそれを制限することが必要なのである。そして、何年も前のコードで、なぜ、このような構成を書いたのか、その理由を正確に覚えているとき - OOPはカートの5輪目に過ぎないのです。

ピーターの問題は、「OOPか手続き型アプローチか」という選択にあるのではなく、ピーターの問題はターゲット層にあるのです。一方ではプログラミングを得意とし、他方では手を動かすことを好む人が不足していること。私はそのような人たちを観察していません。

 
Реter Konow:

1.その通りです。コンストラクタで指定できる要素の数は限られています。したがって、ダイナミックテーブルは限られた行数で構成され、同時に無制限であることが必要である。解決策は、追加されたパラメータ用に特別な配列を作成し、その値をテーブルのセルでスクロールさせることだけです。

2.はい、コンストラクタは、引用されたコードに基づいてエンジンのカーネルを作成します。+は接続ファイルを表示します。そして、カーネルをエンジン（DRIVE）に乗せました。その後、エンジンは目的のGUIを再生することができます。ペアリングファイルはEAに接続され、EAとのやりとりを開始します。

新しいGUIを作るたびに、エンジンに変更を加えなければならないことがわかりました（適切なGUIカーネルを提供する）。これは根本的に間違った解決策だと思います。あなたのエンジンのユーザーが何百人もいると想像してください。しかし、マーケットなどでホストされているエンジンは1つでしかありません。この場合、どうするのでしょうか？各ユーザーが特定のエンジンを配置するために、そのエンジンを自分でダウンロードしなければならないのですか？エンジン用のguiコアはどのように準備するのですか？各ユーザーに個別のエンジンを提供するのでしょうか？- これはすぐに悪夢と化すだろう。つまり、あなたのソリューションはスケーラブルではないのです。

 
Vasiliy Sokolov:

ピーター OOPでは、クラスオブジェクトを作ることで、互いに依存しない複数のオブジェクトを扱うことができるんだ。CCanvas で作業する場合、1つのグラフですべてがうまくいくので、ここでは本当に OOP は必要ないのです。しかし、複数のプロットを異なる領域に表示する必要がある場合、OOPでCCanvasのインスタンスを複数作成しないと難しいです。

あるいは、もうひとつ例を挙げましょう。最近、あるExpert Advisorを修正して、異なるシンボルで同時に取引できるようにしたい（1つのチャート上で動作）、と依頼されました。プロシージャルスタイルでは、異なるシンボルで同時に独立した取引をさせるために、長い時間と複雑な努力が必要だったでしょう。それに対して、私は単純に手続き的なコード全体をクラスに入れて、3つの模範解答を作りました。作業用シンボルなど、それぞれ個別の設定を指定したのですが、一発でちゃんと動きました。このコードは、一回目の試行でそのとおりに動作しました。ユーザーには満足していただけたようです。

あなただってカーネルでOOPを使っているじゃないですか。暗黙の了解でやっているんだろうけど。

カーネルのそれぞれは、OOP用語でいうところのクラスのインスタンスです。そして、どのように呼ぼうと、それはOOPの要素である。しかし、残念ながら、この要素は自作自演であり、何千もの未体験の頭脳によってすでに発明され、磨かれてきたものにその構想力をゆだねてしまうのです。

Vasilyさん、描画機能をクラス化する理由はよくわかりました。なぜなら、それら以外の機能の集合があるからです。

しかし、私の質問は少し違っていた。ニコライは、他のクラスは使わないのに、なぜ、クラスを通して描画関数を呼び出すことを使うのでしょうか？彼は絵を描くだけです。

質問のポイントは、まさにそこでした。

私は、この行為が論理的に無意味であること、そして本人にその自覚がないことを強調しました。

また、解決すべき課題の大きさによって、OOPの使用に 無理が生じることが多いことも強調しました。結局、OOPには枝分かれした分類が必要であり、そのような分類がない場合、わざわざ作る意味があるのでしょうか？

要は、開発者はツールではなく、仕組みの要件に導かれるべきなのです。

 
Vasiliy Sokolov:

ピーター OOPでは、クラスオブジェクトを作ることで、互いに依存しない複数のオブジェクトを扱うことができるんだ。CCanvas で作業する場合、1つのグラフですべてがうまくいくので、ここでは本当に OOP は必要ないのです。しかし、複数のプロットを異なる領域に表示する必要がある場合、OOPでCCanvasのインスタンスを複数作成しないと難しいです。

あるいは、もうひとつ例を挙げましょう。最近、あるExpert Advisorを修正して、異なるシンボルで同時に取引できるようにしたい（1つのチャート上で動作）、と依頼されました。プロシージャルスタイルでは、異なるシンボルで同時に独立した取引をさせるために、長い時間と複雑な努力が必要だったでしょう。それに対して、私は単純に手続き的なコード全体をクラスに入れて、3つの模範解答を作りました。作業用シンボルなど、それぞれ個別の設定を指定したのですが、一発でちゃんと動きました。このコードは、一回目の試行でそのとおりに動作しました。ユーザーには満足していただけたようです。

あなただってカーネルでOOPを使っているじゃないですか。暗黙の了解でやっているんだろうけど。

カーネルのそれぞれは、OOP用語でいうところのクラスのインスタンスです。そして、どのように呼ぼうと、それはOOPの要素である。しかし、残念ながら、この要素は自作自演であり、何千人もの無能な頭脳によってすでに発明され、磨かれてきたものにその構想力をゆだねている。

時間の無駄です。まず、パースへのアドバイザーとの例は湿布です。彼は専門家を書けないし、何があって何が言いたいのか理解できないし、あなたの非常にわかりやすい例も理解できない。見ての通り、彼は、目をパチクリさせて、ニコライに言ったのと同じことをあなたに言うでしょう。第二に、何千人もの先人の知恵を借りずに、自分のバケツで、これまでのどの解よりも優れた超ユニークなコードを自分で作った、と言って、さらに鼻を高くする口実を与えることになるのです。見てください。それこそ、スライダーを使ったユニークなバケットを配置するのでしょう......。

ZS 厳しいことを言ったかもしれませんが、私は、どうしようもないバカには寛容なんです。

 
Vasiliy Sokolov:

カーネルのそれぞれは、OOP用語でいうところのクラスのインスタンスです。そして、どう呼んでもOOP要素である。しかし、残念ながら、この要素は自作自演であり、何千人もの無能な頭脳によってすでに発明され、磨かれてきたものにその構想力をゆだねている。

そうなんですね。それでも、かなりの差があります。私が知る限り、ピーターの店では、この模範的なクラスの店では、ほとんどすべてのものが揃っています。そして、これはOOPのカプセル化パラダイムに適合しない。さらに、グローバル変数 もある。

だからここでは-「OOPの要素」のみ。

Vasilyさん、私がOOPプロジェクトを展開するとき、逆に、「このインターフェースでは、意図されたこと以外は何もできない」と叫ぶ人が出てくると思いますよ(笑)。

 
Vasiliy Sokolov:

新しいGUIを作るたびに、エンジンに変更を加えなければならないことがわかりました（適切なGUIカーネルを装備する）。これは根本的に間違った解決策だと思います。あなたのエンジンのユーザーが何百人もいると想像してください。しかし、マーケットなどでホストされているエンジンは1つでしかありません。この場合、どうするのでしょうか？各ユーザーが特定のエンジンを配置するために、そのエンジンを自分でダウンロードしなければならないのですか？エンジン用のguiコアはどのように準備するのですか？各ユーザーに個別のエンジンを提供するのでしょうか？- これはすぐに悪夢と化すだろう。つまり、あなたのソリューションはスケーラブルではないのです。

いや、ワシリー、君はなんでもかんでも大げさに言うからな（笑)。

デザイナーにボタンがあり、それをクリックすると、すべてのファイルが印刷されます。

そして、エンジンはテキストファイルからカーネルを読み込みます。難しいことではないんです。

 
Nikolai Semko:
ピーターさんは、OOPの応用について何か誤解しているようですね。
申し訳ないが、統合失調症の臭いがする。

特殊な意識の形なのだから、進化を止めてはいけない

1...131132133134135136137138139140141142143144145...184
新しいコメント