MQL5ではOOPは需要になるのでしょうか？ - ページ 2 123456789 新しいコメント Игорь 2009.08.18 14:53 #11 Svinozavr >> : 過程と結果、どちらに興味があるのか) どちらにも興味はありますが、最終的にはなんとなくです。("...OOPはプログラムを遅くする方法をたくさん与えてくれる...") OOPによって手続き的なアプローチよりも速く書けるようになり、それがOOPのすべてのデメリットを上回るとは思えません。誰が必要としているのか、それは他人のために書く開発者であることは明らかです。 例えて言うなら、1人目はナイフでフィリグリーフィギュアを彫り、2人目は同じナイフで指を半分に切り落とした。これのどこがいいんですか？どんな道具でも、「甘いもの」と「完全なクズ」の両方を作ることができるのです。職人気質なのか、才能の閃きがあるのか、全てはプログラマー次第です。これは余談ですが、要するに--FOPがいいなら、さらにそれを使えばいいのです。 Петр 2009.08.18 22:37 #12 サブジャンルを作るにあたり、MT目的のプロジェクトでOOPを支持する議論を見たいと思いました。私の無知のせいでしょうか、媚びを売っているわけではありませんが、見かけませんでした。今は私も見ていません。 皆さんの書き込みを要約してみます（皆さん、ありがとうございます）。 1.プロジェクト実施の利便性とスピード。 それだけ大きなプロジェクトでなければ、その利便性は感じられないということでしょうか。4で作ったものでOOPでやった方が便利なものを教えてくれ。回答はありません。 2.メンテナンス、アップグレード 繰り返しになるが、プロジェクトの規模である。 3.5の方が速いのは、プログラミングの仕方なんて気にする人がいないから。 まあ、全然論外なんですけどね。ノーコメントです。 3.OOPが遅くなる理由としてのハンディキャップ。 普段は手を動かしてプログラムを書いていますが、OOPを使おうと思うとコンピュータに背を向けてしまいますね。)))いいえ、OOPはアルゴリズムの面で手続き型より遅くなります。 ------------ (私はOOPに反対しているわけではなく、MTのタスク（インデックス、スクリプト、Expert Advisorの作成）でOOPが何を与えてくれるのか、自分自身で確かめたかっただけです。 OKです。5日にヘルプがあります。誰が5上のOOPを使用して 書かれたMT4標準からの単純な間接の例を与えるかもしれません？そこで見ることができるようになります。また、文章やプログラムの読みやすさなどから、目で見て遅れを推定することもできます。 Oleksandr 2009.08.18 22:54 #13 Svinozavr писал(а)>>1.利便性とスピード感。 この利便性を感じるには、どれくらいの規模のプロジェクトが必要なのでしょうか？4で作ったものでOOPでやった方が便利なものを教えてくれ。回答はありません。 2.メンテナンス、アップグレード 繰り返しになるが、プロジェクトの規模である。 1.OOPは基本原理を理解している人にはとても便利なものです。シンプルなアプリケーションでも、それを実感できます。どんなアプリケーションでも、OOPで作ると便利です。 2.理解しにくいものでなければ、プロジェクトの規模は問わない。また、プログラムがオブジェクト指向であれば、それを理解することはそれほど難しくはない。一例として、SaxoBankの端末があります。オブジェクト指向言語であるC#で記述されています。1つのDLLには約2万行のコードが含まれています。もしOOPでなかったら、これだけの情報量を理解することはほとんど不可能でしょうし、ましてやそれを近代化することはできません。 Eugeni Neumoin 2009.08.18 23:31 #14 5の問題は、OOPにあるのではありません。4で実装されたものから、大きなプリクラをどのように実装するかはまだ不明です。グラフィカルなオブジェクトを使った 作業が「がんがん」できる。開発者は改善すると約束してくれたが...。...今のところ改善は感じられない。おもちゃのプログラミングができるようになったのです。 ПавелИванович 2009.08.18 23:39 #15 Svinozavr писал(а)>> この利便性を感じるには、どれくらいの規模のプロジェクトが必要なのでしょうか？4で作ったものでOOPでやった方が便利なものを教えてくれ。回答はありません。 おそらく、nenさんの ZUPがいい例でしょう。トリッキーなものが多いですね。内容はもちろんのこと、ソースコードの膨大さ（368Kb v82）だけでも尊敬の念を抱きます。 Eugeni Neumoin 2009.08.18 23:50 #16 5では、誰も手続き型プログラミングを廃止していない。OOPが嫌なら、昔のやり方でプログラムを書けばいい。 しかし、彼らはグラフィカルな指標で大きな問題を作り出してしまった。これらは実現が非常に難しいでしょう。そしてプログラマーにも。そして、グラフ指標を使って手動で取引する人たちへ。プログラマーではなく、一般のトレーダーが再教育を受けなければならない。そして、誰もがきちんとできるわけではないでしょう。 Eugeni Neumoin 2009.08.19 00:10 #17 MQは、自動化されたロボットによる取引しかないと考えているようです。そして、5はまさにロボット向けです。マニュアル取引を クラスとして廃止することにしたそうです。 Avals 2009.08.19 03:05 #18 もはやOOPを核とするものではない（絶対OOPは事実上使えないが）。最初から抽象的なクラスを作り、継承やポリモーフィズムを使って本当のオブジェクトに到達すべきだったのです。例えば、抽象的なメソッドやプロパティを持つカスタム・インジケータの ための抽象的なベース・クラスを作成する場合。グラフィカルなオブジェクト、アカウントでの作業、スケジュールや時系列へのアクセスなど、クラスの階層的なツリーを構築するのがよいでしょう。また、あらかじめ定義された手順や機能については、速度を必要とする初歩的なルーチンのみを残すようにします。そうすれば、どの抽象度からでもプラットフォームの機能を拡張することができ、コードサイズを小さくし、他のプログラマーにとっての読みやすさや理解しやすさを向上させることができるのです。また、MT5ではすでにプロシージャレベルでかなり複雑なものが実装されており（実際、プラットフォーム全体がすぐに使える）、少なくとも作成した内部構造体の記述子へのポインタによるアクセスの可能性を見たことがなく、（ヘルプから判断して）非常に制限されているのが現状です。一般に、OOPの必要性には疑問があり、このような実装では、構造体と動的配置に限定される可能性があります。OOPは、広範なクラス階層によって下からサポートされるべきです。 削除済み 2009.08.19 06:42 #19 プログラムは「書く」ものではなく「読む」ものだと気づくには、プログラミングを1〜3年やる必要があります。 プログラムはコンピュータのために書くのではなく、人間のため（特に自分のため）に書くのだということを理解するのにさらに1〜2年かかる。 そして、OOPやC++がヒューマノイドの考え方や人間の言語を作る方法と矛盾していることに気づくのに1-2年かかります。 他の人のコードを勉強して、最も優れた、最も信頼できるプログラムは古典的なセで書かれていることに気づくまで、さらに1-2年かかります。 まあその後は、C++とOOPで胃が痛くなったというDijkstraのインタビューを読めば十分なのですが。 そしてその後（通算4〜9年）、「OOPについて」の質問はまったく出なくなり、そのような議論には屈託のない笑みが浮かぶだけです。 TheXpert 2009.08.19 07:31 #20 AlexEro >> : そしてその後（計4〜9年）、「OOPについて」の質問はまったくなくなり、そのような議論は見下した笑いを呼び起こすだけです。 >>共感します。 123456789 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
過程と結果、どちらに興味があるのか)
どちらにも興味はありますが、最終的にはなんとなくです。("...OOPはプログラムを遅くする方法をたくさん与えてくれる...")
OOPによって手続き的なアプローチよりも速く書けるようになり、それがOOPのすべてのデメリットを上回るとは思えません。誰が必要としているのか、それは他人のために書く開発者であることは明らかです。
例えて言うなら、1人目はナイフでフィリグリーフィギュアを彫り、2人目は同じナイフで指を半分に切り落とした。これのどこがいいんですか？どんな道具でも、「甘いもの」と「完全なクズ」の両方を作ることができるのです。職人気質なのか、才能の閃きがあるのか、全てはプログラマー次第です。これは余談ですが、要するに--FOPがいいなら、さらにそれを使えばいいのです。
サブジャンルを作るにあたり、MT目的のプロジェクトでOOPを支持する議論を見たいと思いました。私の無知のせいでしょうか、媚びを売っているわけではありませんが、見かけませんでした。今は私も見ていません。
皆さんの書き込みを要約してみます（皆さん、ありがとうございます）。
1.プロジェクト実施の利便性とスピード。
2.メンテナンス、アップグレード
3.5の方が速いのは、プログラミングの仕方なんて気にする人がいないから。
3.OOPが遅くなる理由としてのハンディキャップ。
------------
(私はOOPに反対しているわけではなく、MTのタスク（インデックス、スクリプト、Expert Advisorの作成）でOOPが何を与えてくれるのか、自分自身で確かめたかっただけです。
OKです。5日にヘルプがあります。誰が5上のOOPを使用して 書かれたMT4標準からの単純な間接の例を与えるかもしれません？そこで見ることができるようになります。また、文章やプログラムの読みやすさなどから、目で見て遅れを推定することもできます。
1.利便性とスピード感。
2.メンテナンス、アップグレード
1.OOPは基本原理を理解している人にはとても便利なものです。シンプルなアプリケーションでも、それを実感できます。どんなアプリケーションでも、OOPで作ると便利です。
2.理解しにくいものでなければ、プロジェクトの規模は問わない。また、プログラムがオブジェクト指向であれば、それを理解することはそれほど難しくはない。一例として、SaxoBankの端末があります。オブジェクト指向言語であるC#で記述されています。1つのDLLには約2万行のコードが含まれています。もしOOPでなかったら、これだけの情報量を理解することはほとんど不可能でしょうし、ましてやそれを近代化することはできません。
もはやOOPを核とするものではない（絶対OOPは事実上使えないが）。最初から抽象的なクラスを作り、継承やポリモーフィズムを使って本当のオブジェクトに到達すべきだったのです。例えば、抽象的なメソッドやプロパティを持つカスタム・インジケータの ための抽象的なベース・クラスを作成する場合。グラフィカルなオブジェクト、アカウントでの作業、スケジュールや時系列へのアクセスなど、クラスの階層的なツリーを構築するのがよいでしょう。また、あらかじめ定義された手順や機能については、速度を必要とする初歩的なルーチンのみを残すようにします。そうすれば、どの抽象度からでもプラットフォームの機能を拡張することができ、コードサイズを小さくし、他のプログラマーにとっての読みやすさや理解しやすさを向上させることができるのです。また、MT5ではすでにプロシージャレベルでかなり複雑なものが実装されており（実際、プラットフォーム全体がすぐに使える）、少なくとも作成した内部構造体の記述子へのポインタによるアクセスの可能性を見たことがなく、（ヘルプから判断して）非常に制限されているのが現状です。一般に、OOPの必要性には疑問があり、このような実装では、構造体と動的配置に限定される可能性があります。OOPは、広範なクラス階層によって下からサポートされるべきです。
プログラムは「書く」ものではなく「読む」ものだと気づくには、プログラミングを1〜3年やる必要があります。
プログラムはコンピュータのために書くのではなく、人間のため（特に自分のため）に書くのだということを理解するのにさらに1〜2年かかる。
そして、OOPやC++がヒューマノイドの考え方や人間の言語を作る方法と矛盾していることに気づくのに1-2年かかります。
他の人のコードを勉強して、最も優れた、最も信頼できるプログラムは古典的なセで書かれていることに気づくまで、さらに1-2年かかります。
まあその後は、C++とOOPで胃が痛くなったというDijkstraのインタビューを読めば十分なのですが。
そしてその後（通算4〜9年）、「OOPについて」の質問はまったく出なくなり、そのような議論には屈託のない笑みが浮かぶだけです。
そしてその後（計4〜9年）、「OOPについて」の質問はまったくなくなり、そのような議論は見下した笑いを呼び起こすだけです。
>>共感します。