記事"MetaTraderプログラムを簡単かつ迅速に開発するためのライブラリ(第27部): 取引リクエストの使用 - 指値注文"についてのディスカッション - ページ 4

新しいコメント
 
Artyom Trishkin:

なぜ1秒に1回送信するのか？取引サーバーに殺到させるため？

リクエストの繰り返しの間隔は条件付きです。設定可能です。
 
Artyom Trishkin:

そして、私が計画していることをさらに実現するためには、本格的なオブジェクトが必要なのだ。 しかし、あなたはまだそのことに気づいておらず、課題のごく一部を解決する方法を、さらなる作業のために効果のない形で提供しようとしている。しかし、ここではすべてがリンクしており、一般的なコンセプトは同じである。

とにかく、あなたの意見には感謝している。

ZЫ.そして、そうだね。次のタスクのために軽率に書かれた不完全な解決策を常に書き直すよりは、動いているめちゃくちゃなコードを書くほうが、ひどいことじゃない。

まあ、必要なら必要だ。その理由を見つけるのも面白いかもしれない。

ZЫ.変更や再設計がなくなるのであれば、それはひどいことではないのですが、実際にはそうではありません。オブジェクトであろうとなかろうと、コンセプトの発展が多くのものを再設計することを余儀なくされるのは同じだ。

 
Реter Konow:

まあ、必要なら必要だ。何のために必要なのか気になるところだ。

ZY 変更や再設計をせずに済むのであれば、それに越したことはないが、実際はそうではない。オブジェクトであろうとなかろうと、コンセプトの発展が多くのものを再設計することを余儀なくされるのは同じだ。

あなたは「再設計」と「拡張」の概念を分けて考えていない。再設計とは、既成のものをゴミ箱に捨て、ゼロから新しいものを書くこと。そして拡張とは、既製品に新しい機能を追加することだ。

ほとんどの場合、ここでは追加するだけで、記事から記事へと書き換えることはない。
しかし、ゼロから新しいものを作る場合、そう、多くの書き換えがある。しかし、それは記事の舞台裏でのことだ。唯一の2つの例外は、ごく初期には、すべてのライブラリ・コンポーネントのさらなる機能性を拡張するために、すでに公開されているものに小さな修正を加えていたこと、そして今は-最初は-まず簡略化したコードでソリューションをテストし、それから-1つの記事を通して-本格的なオブジェクト・トレード・クエリを 作成し、それから-それらを使った作業クラスを作成していることです。
現在では、すべてが1つの場所、つまりトレード・クラスで行われている。それはトレードではあるが、トレード・メソッドではなく、トレード・メソッドを管理する方法なのだ。

 
Artyom Trishkin:

あなたは「やり直し」と「拡張」の概念を分けて考えていない。再設計とは、既成のものを捨てて、ゼロから新しいものを書くこと。そして拡張とは、既成のものに新しい機能を追加することである。

ほとんどの場合、ここでは追加するだけで、記事から記事へと書き換えることはない。
しかし、ゼロから新しいものを作る場合、そう、多くの書き換えがある。しかし、それは記事の舞台裏でのことだ。唯一の2つの例外は、ごく初期には、すべてのライブラリコンポーネントのさらなる機能を拡張するために、すでに公開されているものに小さな修正が加えられていたこと、そして現在では、最初は簡略化されたコードでソリューションがテストされ、その後、1つの記事を通して、本格的なオブジェクト、つまり取引要求が 作成され、その後、それらを使った作業クラスが作成されていることです。
今、すべてが1つの場所で行われている-トレードクラスの中で。トレードではあるが、トレード・メソッドではない。トレード・メソッドを管理する方法なのだ。

私はすべてを完璧に共有しているし、自分が何を言っているのかもわかっている。そして、あなたは私が言っていることの的外れをしている。

世の中のあらゆるものをオブジェクトにすることに夢中になっているのは、あなたがその概念的な境界線を知らないことを示している。OOPには、すべてをオブジェクトにしなければならないというルールはないが、あなたはそれを知らないようだ。

オブジェクトの扱いにどれだけの時間を費やすことになるか考えてみてほしい。オブジェクトの必要性は、私が指摘した簡潔ですぐに使える解決策によってすでに損なわれているのだ。これで他に何が思いつく？私には想像力が足りない。あなたならできるかもしれない。どうぞ。

 

何がオブジェクトになり、何がオブジェクトにならないかという質問に対して。

1.トレード・リクエストは オブジェクトである。

2. 保留中のトレード・リクエストはオブジェクトではない。なぜか？なぜなら、もしこれをオブジェクトにした場合、それは取引依頼オブジェクトの完全なコピーとなり、1つの相違点、つまりリピートと削除基準があるからです。これは保留中の 取引依頼を 取引依頼から「アンパック」するには小さすぎる違いです。

 
まあ、これも意見だ。
 
私たちのアプローチの違いを理解するなぜ単純な解決策があなたには通用しないのか。

あなたは「すべてがオブジェクト」という原則に従っている。私は「すべてがオブジェクト」という原則に従っている。

あなたは小さくて単純なオブジェクトをたくさん作るが、私は大きくて非常に複雑なものを1つ作る。私の解決策は、発展させるためにオブジェクトの内容を圧縮することを要求し、あなたの解決策は、正当な実体として行われるために、それぞれのオブジェクトに肉付けすることを要求する。

私が示した解決策は、ディファード・クエリー・オブジェクトを必要としません。あなたの次の記事は、サーバーへの失敗したリクエストを再生するという単純なタスクの周りに、あなたが作り出したエンティティの乱雑さとそれらの相互関係を示しています。

必要なのは、満たされなかったサーバーリクエストを繰り返すことだけなのに、あなたの解決策は驚くことに、ジャングルの中のように迷い込んでしまうようなエンティティの世界を作り出している。

私はこのプログラミングのやり方に疑問を感じ、どう感じたらいいのかわからなくなっている。一方では賞賛に値するし、他方では言語道断だ。このような方法で問題を解決していたら、自分のやりたいことをやるだけの人生がなくなってしまう。だから、明確な評価はできない。

ひとつだけわかっているのは、もしあなたが壁に押し付けられ、明日の夕方までに解決策を要求されたとしても、あなたはモノを作らず、私の解決策を使うだろう。


 
Реter Konow:
...あなたは小さくてシンプルなオブジェクトをたくさん作るけど、私は大きくて複雑なオブジェクトを1つ作る...。

ピーター、これはスーパークラスか？あなたが詰め込むことができないものを詰め込むことができますか？:-)本には、それは良くないと書いてあるんだけど......。

Artyomに指摘しておきたいのですが、Anatolyが グラフィックスの連載を書いたとき、クラス間の相互関係の構造（階層と読みます）をあげていました。例えば

アルチョム、君は素晴らしい仕事をした。教科書が1冊書けるよ。ドキュメンテーションよりも詳しいところもある。そしてクールだ。でも時々、資料の中に十分なイラストがないことがある。もちろん個人的な意見だが...。

 
Denis Kirichenko:

ピーター、これは何なんだ？詰め込めないものを詰め込むのか？:-)本には良くないって書いてあるけど...。

Artyomに指摘しておきたいのだが、Anatolyが グラフィックスの連載を書いたとき、彼はクラス間の相互関係の構造（階層と読む）をあげていた。例えば

アルチョム、君は素晴らしい仕事をした。教科書が1冊書けるよ。ドキュメンテーションよりも詳しいところもある。それは素晴らしいことだ。でも、時々、資料の中に十分な図解がないことがある。もちろん、僕の意見だけど...。

ありがとう。
ヒエラルキー構造は後ほど最終決定する。急に変更する必要が出てきても、やり直したくないからね。
 
Denis Kirichenko:

ピーター、これは何なんだ？詰め込めないものを詰め込むのか？:-)本には良くないと書いてあるけど...。

何でもうまくいくし、うまくいく。人それぞれだ。
記事を読んでいるんだけど、"エンティティ・ジェネレーター"、つまりこれらすべてが行われる原理が見つからないんだ。私はこのように考えることを学び、なぜ違う考え方をするのかを理解しようとしている。もしあるとすれば）違う考え方をすることの利点は何だろう？私はアルチョムにもライブラリー構想について話した。


12345
新しいコメント