MQL5におけるOOPに関する質問 - ページ 27 1...202122232425262728293031323334...96 新しいコメント TheXpert 2019.09.05 16:41 #261 Alexey Navoykov: 特にどの発言に根拠がないのか？ は十分あります。 この記事は、OOPの人たちからモメるために作られた投げやりな記事で、単にmqlにFP用の言語ツールがないだけなので、mqlとは関係ない。 ということで、ここで議論しても仕方がない。 Alexey Navoykov 2019.09.05 19:32 #262 TheXpert: は十分あります。 この記事は、OOPの人たちから炎上するために作られた投げやりなもので、mqlには関係ありません。なぜなら、mqlにはFP用の言語ツールがないだけだからです。 ということで、ここで議論しても仕方がない。 しかし、少なくとも、間違った（軽率な）OOPの使い 方の問題点を指摘しています。 OOPを使うこと自体が万能で、コードの品質を保証してくれるという印象を初心者に与えないためにも、ここでは非常に有効だと思います。 Dmitry Fedoseev 2019.09.05 19:49 #263 TheXpert: は十分あります。 この記事は、OOPの人たちから炎上するために作られた投げやりなもので、mqlには関係ありません。なぜなら、mqlにはFP用の言語ツールがないだけ だからです。 ということで、ここで議論しても仕方がない。 コメントは不要です。 Dmitry Fedoseev 2019.09.05 19:58 #264 Vasiliy Sokolov: FPの支持者は、ラムダ計算が有限個の状態とその間の遷移を持つチューリング機械によって実行されること、すなわち同じカウンタ、分岐、goto命令が使用されることを意識的に忘れているのである。ですから、FPがCやC#、Javaのような古典的な言語以上のものを提供すると主張するのは、少なくとも間違っているのです。 Vasily、この記事はあなたにとって非常に有益なものです。 Igor Makanu 2019.09.05 20:10 #265 Dmitry Fedoseev: Vasily、この記事はあなたにとって非常に有益なものです。 私はこの人の記事のスタイルがとても好きなんです。 彼の記事のスタイルが好きなので、きれいで読みやすいといいなと思います。 Dmitry Fedoseev 2019.09.05 20:26 #266 Igor Makanu: お世辞でもなんでもなく、私は彼の文体がとても好きです。 コードはきれいで読みやすく、ぜひ自分のものにしたいと思います。 残念ながら、私はこの話を支持することはできません。記事を読んだり、コードを見たりしたわけではありません。それは、別のことだった。 Igor Makanu 2019.09.05 20:48 #267 Dmitry Fedoseev: 残念ながら、私はこの会話をサポートすることができません - 私は記事を読んでいないし、コードも見ていないのです。それは、別のことだった。 私は、MQLにおけるOOPの目的意識を明確にするために、OOPについて意見を述べることしかできません。 コードを完成させました。どんな結果になるのか、興味深かったです。 今、私は注文を扱うためのすべての関数をクラスにラップしました。そして、コードを整理し、クラスのフィールドがプライベートであるため、関数のパラメータを削除しました - 意味がありません...。全く使えないコードが送られてきました。 確かに、小さなメソッドを追加してクラスの機能を拡張できるのは便利なのですが、将来的なことを考えると ...とか、コンパイラが未使用のコードを実行ファイルに含めないことを承知で新しいメソッドを追加するとか、...。...または...もう一度書き直す - だから、全体として、我々は注文を扱うためのクラスのある種のモンスターを持っています。 すなわち、普遍性料は数ヶ月後には読めなくなるような肥大化したコードであり、そのコードを継承することで、クラスの中で何が余計なのかを見つける必要がなくなるのです - あなたの時間を無駄にしすぎましたね 原則的に、これから実行するタスクに応じたメソッド名で読むことができます。全般的に満足のいく結果ではありません。 Алексей Тарабанов 2019.09.05 21:00 #268 Igor Makanu: 私は、MQLにおけるOOPの合理性を理解するために、OOPについての私の意見を述べることができます。 私はコードを仕上げました - それは最終的に出てくるものを見るのは面白かったです、最初は私が使用していた書き方でした - 注文で動作するサービス関数をデバッグし、私は特定のタスクでのみ使用する予定のデータや小さなメソッドを保持し、私は クラス（手続きスタイル）から注文で動作する関数を呼び出す OOPを挿入しました。 今、私は注文を扱うためのすべての関数をクラスにラップしました。そして、コードを整理し、クラスのフィールドがプライベートであるため、関数のパラメータを削除しました - 意味がありません...。全く使えないコードが送られてきました。 確かに、小さなメソッドを追加したり、クラスの機能を拡張できるのは便利ですが、将来的な利用を考えると ...とか、コンパイラが未使用のコードを実行ファイルに含めないことを承知で新しいメソッドを追加するとか、...。...または...もう一度書き直す - だから、全体として、我々は注文を扱うためのクラスのある種のモンスターを持っています。 すなわち、普遍性料は数ヶ月後には読めなくなるような肥大化したコードであり、そのコードを継承することで、クラスの中で何が余計なのかを見つける必要がなくなるのです - あなたの時間を無駄にしすぎましたね 原則的に、これから実行するタスクに応じたメソッド名で読むことができます。全般的に満足のいく結果ではありません。 要するに、うんこして迷子になったのだ。 Igor Makanu 2019.09.05 21:03 #269 Алексей Тарабанов: 要するに、「糞して出て行け」ということだ。 うーん、誰が出たんだろう？何言ってるんだ、わかったよ...夜中のコメントばかりで、何が何だかわからなくなりますね。 Dmitry Fedoseev 2019.09.05 21:11 #270 Igor Makanu: ... また、クラスを使わないと、SymbolInfoDouble(_Symbol,SYMBOL_BID)のようなものを常に書いていると、疲れてしまうでしょう。 そんなのが毎回踊っている。カッコもアンダースコアも、capslockを押すか（そして見ずにどこかで、大文字の文字列を全部入力して打ち直す）、シフターを押し続けるか、迷うところだ。少なくとも、そこにOOPの有用性がある。少なくとも、これらの機能のためのクラスを作るのであれば、そうです - 巨大なものです。自分のために書くのであれば、問題ありません。オーダーの操作に関しては、頻繁に使う関数はそれほど多くないので、いくつかの関数をライブラリに入れればいいだけです。しかし、一般的には、まだ理想的なアプローチはありません。 1...202122232425262728293031323334...96 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
特にどの発言に根拠がないのか？
は十分あります。
この記事は、OOPの人たちからモメるために作られた投げやりな記事で、単にmqlにFP用の言語ツールがないだけなので、mqlとは関係ない。
ということで、ここで議論しても仕方がない。
は十分あります。
この記事は、OOPの人たちから炎上するために作られた投げやりなもので、mqlには関係ありません。なぜなら、mqlにはFP用の言語ツールがないだけだからです。
ということで、ここで議論しても仕方がない。
は十分あります。
この記事は、OOPの人たちから炎上するために作られた投げやりなもので、mqlには関係ありません。なぜなら、mqlにはFP用の言語ツールがないだけ だからです。
ということで、ここで議論しても仕方がない。
コメントは不要です。
FPの支持者は、ラムダ計算が有限個の状態とその間の遷移を持つチューリング機械によって実行されること、すなわち同じカウンタ、分岐、goto命令が使用されることを意識的に忘れているのである。ですから、FPがCやC#、Javaのような古典的な言語以上のものを提供すると主張するのは、少なくとも間違っているのです。
Vasily、この記事はあなたにとって非常に有益なものです。
Vasily、この記事はあなたにとって非常に有益なものです。
私はこの人の記事のスタイルがとても好きなんです。
彼の記事のスタイルが好きなので、きれいで読みやすいといいなと思います。
お世辞でもなんでもなく、私は彼の文体がとても好きです。
コードはきれいで読みやすく、ぜひ自分のものにしたいと思います。
残念ながら、私はこの話を支持することはできません。記事を読んだり、コードを見たりしたわけではありません。それは、別のことだった。
残念ながら、私はこの会話をサポートすることができません - 私は記事を読んでいないし、コードも見ていないのです。それは、別のことだった。
私は、MQLにおけるOOPの目的意識を明確にするために、OOPについて意見を述べることしかできません。 コードを完成させました。どんな結果になるのか、興味深かったです。
今、私は注文を扱うためのすべての関数をクラスにラップしました。そして、コードを整理し、クラスのフィールドがプライベートであるため、関数のパラメータを削除しました - 意味がありません...。全く使えないコードが送られてきました。
確かに、小さなメソッドを追加してクラスの機能を拡張できるのは便利なのですが、将来的なことを考えると ...とか、コンパイラが未使用のコードを実行ファイルに含めないことを承知で新しいメソッドを追加するとか、...。...または...もう一度書き直す - だから、全体として、我々は注文を扱うためのクラスのある種のモンスターを持っています。
すなわち、普遍性料は数ヶ月後には読めなくなるような肥大化したコードであり、そのコードを継承することで、クラスの中で何が余計なのかを見つける必要がなくなるのです - あなたの時間を無駄にしすぎましたね
原則的に、これから実行するタスクに応じたメソッド名で読むことができます。全般的に満足のいく結果ではありません。
私は、MQLにおけるOOPの合理性を理解するために、OOPについての私の意見を述べることができます。 私はコードを仕上げました - それは最終的に出てくるものを見るのは面白かったです、最初は私が使用していた書き方でした - 注文で動作するサービス関数をデバッグし、私は特定のタスクでのみ使用する予定のデータや小さなメソッドを保持し、私は クラス（手続きスタイル）から注文で動作する関数を呼び出す OOPを挿入しました。
今、私は注文を扱うためのすべての関数をクラスにラップしました。そして、コードを整理し、クラスのフィールドがプライベートであるため、関数のパラメータを削除しました - 意味がありません...。全く使えないコードが送られてきました。
確かに、小さなメソッドを追加したり、クラスの機能を拡張できるのは便利ですが、将来的な利用を考えると ...とか、コンパイラが未使用のコードを実行ファイルに含めないことを承知で新しいメソッドを追加するとか、...。...または...もう一度書き直す - だから、全体として、我々は注文を扱うためのクラスのある種のモンスターを持っています。
すなわち、普遍性料は数ヶ月後には読めなくなるような肥大化したコードであり、そのコードを継承することで、クラスの中で何が余計なのかを見つける必要がなくなるのです - あなたの時間を無駄にしすぎましたね
原則的に、これから実行するタスクに応じたメソッド名で読むことができます。全般的に満足のいく結果ではありません。
要するに、うんこして迷子になったのだ。
要するに、「糞して出て行け」ということだ。
うーん、誰が出たんだろう？何言ってるんだ、わかったよ...夜中のコメントばかりで、何が何だかわからなくなりますね。
...
また、クラスを使わないと、SymbolInfoDouble(_Symbol,SYMBOL_BID)のようなものを常に書いていると、疲れてしまうでしょう。 そんなのが毎回踊っている。カッコもアンダースコアも、capslockを押すか（そして見ずにどこかで、大文字の文字列を全部入力して打ち直す）、シフターを押し続けるか、迷うところだ。少なくとも、そこにOOPの有用性がある。少なくとも、これらの機能のためのクラスを作るのであれば、そうです - 巨大なものです。自分のために書くのであれば、問題ありません。オーダーの操作に関しては、頻繁に使う関数はそれほど多くないので、いくつかの関数をライブラリに入れればいいだけです。しかし、一般的には、まだ理想的なアプローチはありません。