手続き型コードにできなくて、OOPコードにできることは何ですか？ - ページ 4 12345 新しいコメント Donald Gibson 2016.05.25 07:11 #31 Doerk Hilger:プロフェッショナルな人が「証拠」としてcompexライブラリを投稿しているとでも思っているのでしょうか？）私はここの市場で売ることができない何か準備ができているリンクをあなたに投稿することができますが、私がそれをしたらAlainは私を蹴るつもりです;)私のプロフィールを見て、壁の写真を見て、アイデアを得るか、私にPMを送ることができます。他のプラットフォーム？これほど強力なコンパイラを持つプラットフォームは他にはないでしょう。全くです。James Cater - コメントありがとうございます。MT以外のプラットフォームもありますし、コンパイラが強力であろうがなかろうが、簡単なコードを書けるのであれば、私は気にしません。私たちは皆、まだ学んでいる途中です。私の知る限り、これはコンテストではなく、むしろ知識とサポートを交換するための場所です。ところで、このフォーラムで100万行のプログラムを書く人がいるとは思っていません。 Juan Fernandez 2016.05.25 07:33 #32 Alain Verleyen: Dirk: ポイントがずれていますね。専門家でない人たちは、シンプルでわかりやすいコード例を求めていますし、実際、それがこのトピックの目標でした。しかし、それは専門家の理解を完全に超えているようです。最新の言語では、コーディングの知識がない人でも「コーダー」の仲間入りができるように、物事を単純化しようとしています。その最たるものが、HTMLという疑似言語だ。そして、これが大きな間違いなのです。MT5が開発されたとき、多くの「初心者」は、OOPスタイルが難しいからと非難した。しかし、実際のところ、どんな仕事にもプロがいる。もし、プラットフォームを改善したいのであれば、それを複雑にしなければならない。より多くの機能を、より柔軟に。コーディングの知識のない人にそれをやらせても、それは家を建てることを知らない人が作るようなものだ。大惨事になりますよ。プロジェクトの 長さについては、コーダーによる。私のライブラリは、MQL言語用の中型のものです。他の人は、ツールを作るための小さなライブラリしか必要としない。私の場合、フレームワークの作成に時間を割いた方が、将来の開発時間を短縮できるし、開発もシンプルになる。複雑なUIを作ったり、他のプロジェクトでコードを再利用したりするのであれば、その方がスマートだと思います。 Alain Verleyen 2016.05.25 07:47 #33 Juan Fernandez:最新の言語では、コーディングの知識がない人でも「コーダー」の仲間入りができるように、物事を単純化しようとしています。その最たるものが、HTMLという疑似言語だ。そして、これが大きな間違いなのです。MT5が開発されたとき、多くの「初心者」は、OOPスタイルが難しいからと非難した。しかし、実際のところ、どんな仕事にもプロがいる。もし、プラットフォームを改善したいのであれば、それを複雑にしなければならない。より多くの機能を、より柔軟に。コーディングの知識のない人にそれをやらせても、それは家を建てることを知らない人が作るようなものだ。大惨事になりますよ。プロジェクトの長さについては、コーダーによる。私のライブラリは、MQL言語用の中型のものです。他の人は、ツールを作るための小さなライブラリしか必要としない。私の場合、フレームワークの作成に時間を割いた方が、将来の開発時間を短縮できるし、開発もシンプルになる。複雑なUIを作ったり、他のプロジェクトでコードを再利用したりするのであれば、その方がスマートだと思います。では、人は知識を得ることができないのですか？ Alain Verleyen 2016.05.25 07:58 #34 プロシージャルとOOPは無駄な議論です、3年前にすでに議論され、私の答えは完全に有効です、これ以上何もここで言われていません: トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム プログラマーの皆さん。あなたの好みは何ですか？OOP vs プロシージャル アラン・ヴェリエン, 2013.06.11 13:11 この投票は、何もしないことを好む人のためのオプションが欠けています。これは好みの問題だけでなく、ちょっとしたスクリプトや簡単なEAにOOPを使うのは意味がない。OOPは常に作業を追加し、複雑なプロジェクトやコードの再利用性（同じコードを複数のプロジェクトで使用する）にのみ有利 です。もし、ある人が大きなプロジェクトを持っていても、比較的単純な ものであれば、 自動的に OOPを 使わなければ ならないということにはならない のです。 Metaquotesが開発したMQL5 Wizardを 見れば、OOPの大きな可能性がわかります。このようなツールを手続き型プログラミングで開発することは非常に 困難ですが、 可能性は あります。 OOPは使うべきものです。DoerkとJamesがよく言っているように、複雑なプロジェクトで使うべきだ。コードを再利用したいとき 今後は、上記のようなケースで、なぜ、どのようにOOPを使うのが良いのか、具体的なコード例がない投稿は受け付けないことにします。 Donald Gibson 2016.05.25 09:09 #35 Alain Verleyen:プロシージャルとOOPの比較は無駄な議論です。3年前にすでに議論され、私の答えは完全に妥当で、これ以上何も言われません。OOPは使われるべきです。DoerkやJamesがよく言っているように、複雑なプロジェクトでは。コードを再利用したいとき。 これからは、上記のような場合になぜ、どのようにOOPを使うのが良いのかを示す具体的なコード例がない投稿は受け入れないことにします。 ありがとうございました。 Mrluck07 2018.03.28 10:25 #36 このトピックを全部読んで、これは面白いと思ったのですが、機械語は手続き型ではないのですか？つまり、高級言語も、OOPも、最終的にはすべてコンパイラで手続き型に翻訳されるわけですよね？もし、すべての言語が手続き的な機械語に翻訳されるのであれば、プログラマがスキルを身につければ、すべてが手続き的であると言えるのではないでしょうか。 Amir Yacoby 2018.03.28 11:49 #37 Mrluck07: このトピックを全部読んで、これは面白いと思ったのですが、機械語は手続き型ではないのですか？つまり、高級言語も、OOPも、最終的にはすべてコンパイラで手続き型に変換されるわけですよね？もし、すべての言語が手続き的な機械語に翻訳されるなら、プログラマが技術を身につければ、すべてが手続き的に行えると言えるのではないでしょうか。理論的にはすべて手続き型にできる。しかし、それは現実的ではありません。 レンガは何千何万という砂の粒子でできているので、レンガがなくても砂だけで家を建てることはできる。 でも、レンガがあっても誰も挑戦しない。 飛行機は、翼、車輪、座席、コンピュータなど、既製の部品で作られています。最終的には金属かプラスチックかガラスでできています。しかし、誰も純粋なガラス、プラスチック、金属から飛行機を作ろうとはしません。 一般的な議論について（Alainと他の人への返答として）。CArrayObj（オブジェクトの配列）を見てみましょう。これだけで、OOのパワーとは何か（これよりはるかに大きなものです）を答えるのに十分です。これはどんなオブジェクトの配列でも格納することができます - 例えば指標のような。 そして、これらの異なるインジケータのために複雑なことをするのは、まったく労力がかかりません。そして、これに新しい力を加えたい場合、例えばインジケータのバッファが クロスしたときにそれを知りたい場合、CIndicatorにメソッドを置くだけでいいのです。といった具合です。プロシージャルでどうやるんだ？ そしてこれは、ストラテジー、トレード、ディール、シグナルなど、あらゆる局面で行うことができます。 Alain Verleyen 2018.03.28 12:34 #38 Amir Yacoby:手続き型では理論的には何でもできるのです。しかし、それは現実的ではありません。 レンガは何千何万という砂の粒子でできているので、レンガがなくても砂だけで家を建てることはできます。 でも、レンガがあっても誰も挑戦しない。 飛行機は、翼、車輪、座席、コンピュータなど、既製の部品で作られています。最終的には金属かプラスチックかガラスでできています。しかし、誰も純粋なガラス、プラスチック、金属から飛行機を作ろうとはしません。 一般的な議論について（Alainと他の人への返答として）。CArrayObj（オブジェクトの配列）を見てみましょう。これだけで、OOのパワーとは何か（これよりはるかに大きなものです）を答えるのに十分です。これはどんなオブジェクトの配列でも格納することができます - 例えば指標のような。 そして、これらの異なるインジケータのために複雑なことをするのは、まったく労力がかかりません。そして、これに新しい力を加えたい場合、例えばインジケータのバッファが クロスしたときにそれを知りたい場合、CIndicatorにメソッドを置くだけでいいのです。といった具合です。プロシージャルでどうやるんだ？ そしてこれは、ストラテジー、トレード、ディール、シグナルなど、あらゆる局面で行うことができます。このトピックは意図的に挑発的なものでしたが、主要な質問（手続き的なコードにできなくて、OOPにできることは何か）に対する答えは「Nothing（何もない）」です。 OOPは確かにレンガを構築し使用する唯一の方法ではありません。少なくとも、手続き型コードと同じくらい（そしておそらくもっと）、OOPでは悪いコードを作成する方法があります。Metaquotesが提供する "標準ライブラリ "を見てください。 OOP対手続き型は無駄で終わりのない議論です。もっと有益なのは、「質の高いコードを作るにはどうしたらいいか？OOPの有無、手続き型の有無、どのようなプログラミングパラダイムを使うか使わないか」です。もし、あなたのニーズが木造の家を建てることであるなら、レンガは必要ないでしょう。 Amir Yacoby 2018.03.28 12:47 #39 アラン、刺激的だったでしょう？そして、優れたプログラミングは、きっとあらゆるところで実践できるはずです。しかし、すべての世界はオブジェクトで構成されており、それはトレーディングの世界も含まれます。もちろん、両方ともうまく書ければの話ですが。 Mrluck07 2018.03.28 12:56 #40 Amir Yacoby:すべてはプロシージャルで理論的には可能です。実用的ではないんです。 レンガは何千何万という砂の粒子でできているので、レンガがなくても砂だけで家を建てることができます。 でも、レンガがあっても誰も挑戦しない。 飛行機は、翼、車輪、座席、コンピュータなど、既製の部品で作られています。最終的には金属かプラスチックかガラスでできています。しかし、誰も純粋なガラス、プラスチック、金属から飛行機を作ろうとはしません。 一般的な議論について（Alainと他の人への返答として）。CArrayObj（オブジェクトの配列）を見てみましょう。これだけで、OOのパワーとは何か（これよりはるかに大きなものです）を答えるのに十分です。これはどんなオブジェクトの配列でも格納することができます - 例えば指標のような。 そして、これらの異なるインジケータのために複雑なことをするのは、まったく労力がかかりません。そして、これに新しい力を加えたい場合、例えばインジケータのバッファが クロスしたときにそれを知りたい場合、CIndicatorにメソッドを置くだけでいいのです。といった具合です。プロシージャルでどうやるんだ？ そしてこれは、ストラテジー、トレード、ディール、シグナルなど、あらゆる局面で行うことができます。あなたの例では、OOコードを書いてコンパイルをクリックすると、マシン・コードが生成されます。しかし、このマシンコードは手続き型なのか、そうでないのか？私は本当に答えを知らない、ここで誰か知っていますか？もし、機械語コードが手続き的であるなら、OOはより高度な言語と呼ぶことができるでしょう、それはコーディングを容易にするだけで、特別なものではありません。そこで質問ですが、元コードはプロデッショナルなのでしょうか、そうでないのでしょうか？ 12345 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
プロフェッショナルな人が「証拠」としてcompexライブラリを投稿しているとでも思っているのでしょうか？）私はここの市場で売ることができない何か準備ができているリンクをあなたに投稿することができますが、私がそれをしたらAlainは私を蹴るつもりです;)私のプロフィールを見て、壁の写真を見て、アイデアを得るか、私にPMを送ることができます。
他のプラットフォーム？これほど強力なコンパイラを持つプラットフォームは他にはないでしょう。全くです。
James Cater - コメントありがとうございます。
MT以外のプラットフォームもありますし、コンパイラが強力であろうがなかろうが、簡単なコードを書けるのであれば、私は気にしません。
私たちは皆、まだ学んでいる途中です。私の知る限り、これはコンテストではなく、むしろ知識とサポートを交換するための場所です。
ところで、このフォーラムで100万行のプログラムを書く人がいるとは思っていません。
Dirk: ポイントがずれていますね。専門家でない人たちは、シンプルでわかりやすいコード例を求めていますし、実際、それがこのトピックの目標でした。しかし、それは専門家の理解を完全に超えているようです。
最新の言語では、コーディングの知識がない人でも「コーダー」の仲間入りができるように、物事を単純化しようとしています。その最たるものが、HTMLという疑似言語だ。そして、これが大きな間違いなのです。MT5が開発されたとき、多くの「初心者」は、OOPスタイルが難しいからと非難した。しかし、実際のところ、どんな仕事にもプロがいる。もし、プラットフォームを改善したいのであれば、それを複雑にしなければならない。より多くの機能を、より柔軟に。コーディングの知識のない人にそれをやらせても、それは家を建てることを知らない人が作るようなものだ。大惨事になりますよ。
プロジェクトの 長さについては、コーダーによる。私のライブラリは、MQL言語用の中型のものです。他の人は、ツールを作るための小さなライブラリしか必要としない。私の場合、フレームワークの作成に時間を割いた方が、将来の開発時間を短縮できるし、開発もシンプルになる。複雑なUIを作ったり、他のプロジェクトでコードを再利用したりするのであれば、その方がスマートだと思います。
最新の言語では、コーディングの知識がない人でも「コーダー」の仲間入りができるように、物事を単純化しようとしています。その最たるものが、HTMLという疑似言語だ。そして、これが大きな間違いなのです。MT5が開発されたとき、多くの「初心者」は、OOPスタイルが難しいからと非難した。しかし、実際のところ、どんな仕事にもプロがいる。もし、プラットフォームを改善したいのであれば、それを複雑にしなければならない。より多くの機能を、より柔軟に。コーディングの知識のない人にそれをやらせても、それは家を建てることを知らない人が作るようなものだ。大惨事になりますよ。
プロジェクトの長さについては、コーダーによる。私のライブラリは、MQL言語用の中型のものです。他の人は、ツールを作るための小さなライブラリしか必要としない。私の場合、フレームワークの作成に時間を割いた方が、将来の開発時間を短縮できるし、開発もシンプルになる。複雑なUIを作ったり、他のプロジェクトでコードを再利用したりするのであれば、その方がスマートだと思います。
では、人は知識を得ることができないのですか？
プロシージャルとOOPは無駄な議論です、3年前にすでに議論され、私の答えは完全に有効です、これ以上何もここで言われていません:
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
プログラマーの皆さん。あなたの好みは何ですか？OOP vs プロシージャル
アラン・ヴェリエン, 2013.06.11 13:11
この投票は、何もしないことを好む人のためのオプションが欠けています。これは好みの問題だけでなく、ちょっとしたスクリプトや簡単なEAにOOPを使うのは意味がない。OOPは常に作業を追加し、複雑なプロジェクトやコードの再利用性（同じコードを複数のプロジェクトで使用する）にのみ有利 です。もし、ある人が大きなプロジェクトを持っていても、比較的単純な ものであれば、 自動的に OOPを 使わなければ ならないということにはならない のです。
Metaquotesが開発したMQL5 Wizardを 見れば、OOPの大きな可能性がわかります。このようなツールを手続き型プログラミングで開発することは非常に 困難ですが、 可能性は あります。
OOPは使うべきものです。
今後は、上記のようなケースで、なぜ、どのようにOOPを使うのが良いのか、具体的なコード例がない投稿は受け付けないことにします。
プロシージャルとOOPの比較は無駄な議論です。3年前にすでに議論され、私の答えは完全に妥当で、これ以上何も言われません。
OOPは使われるべきです。
これからは、上記のような場合になぜ、どのようにOOPを使うのが良いのかを示す具体的なコード例がない投稿は受け入れないことにします。
このトピックを全部読んで、これは面白いと思ったのですが、機械語は手続き型ではないのですか？つまり、高級言語も、OOPも、最終的にはすべてコンパイラで手続き型に変換されるわけですよね？もし、すべての言語が手続き的な機械語に翻訳されるなら、プログラマが技術を身につければ、すべてが手続き的に行えると言えるのではないでしょうか。
理論的にはすべて手続き型にできる。しかし、それは現実的ではありません。
レンガは何千何万という砂の粒子でできているので、レンガがなくても砂だけで家を建てることはできる。
でも、レンガがあっても誰も挑戦しない。
飛行機は、翼、車輪、座席、コンピュータなど、既製の部品で作られています。最終的には金属かプラスチックかガラスでできています。しかし、誰も純粋なガラス、プラスチック、金属から飛行機を作ろうとはしません。
一般的な議論について（Alainと他の人への返答として）。CArrayObj（オブジェクトの配列）を見てみましょう。これだけで、OOのパワーとは何か（これよりはるかに大きなものです）を答えるのに十分です。これはどんなオブジェクトの配列でも格納することができます - 例えば指標のような。
そして、これらの異なるインジケータのために複雑なことをするのは、まったく労力がかかりません。そして、これに新しい力を加えたい場合、例えばインジケータのバッファが クロスしたときにそれを知りたい場合、CIndicatorにメソッドを置くだけでいいのです。といった具合です。プロシージャルでどうやるんだ？
そしてこれは、ストラテジー、トレード、ディール、シグナルなど、あらゆる局面で行うことができます。
手続き型では理論的には何でもできるのです。しかし、それは現実的ではありません。
レンガは何千何万という砂の粒子でできているので、レンガがなくても砂だけで家を建てることはできます。
でも、レンガがあっても誰も挑戦しない。
飛行機は、翼、車輪、座席、コンピュータなど、既製の部品で作られています。最終的には金属かプラスチックかガラスでできています。しかし、誰も純粋なガラス、プラスチック、金属から飛行機を作ろうとはしません。
一般的な議論について（Alainと他の人への返答として）。CArrayObj（オブジェクトの配列）を見てみましょう。これだけで、OOのパワーとは何か（これよりはるかに大きなものです）を答えるのに十分です。これはどんなオブジェクトの配列でも格納することができます - 例えば指標のような。
そして、これらの異なるインジケータのために複雑なことをするのは、まったく労力がかかりません。そして、これに新しい力を加えたい場合、例えばインジケータのバッファが クロスしたときにそれを知りたい場合、CIndicatorにメソッドを置くだけでいいのです。といった具合です。プロシージャルでどうやるんだ？
そしてこれは、ストラテジー、トレード、ディール、シグナルなど、あらゆる局面で行うことができます。
このトピックは意図的に挑発的なものでしたが、主要な質問（手続き的なコードにできなくて、OOPにできることは何か）に対する答えは「Nothing（何もない）」です。
OOPは確かにレンガを構築し使用する唯一の方法ではありません。少なくとも、手続き型コードと同じくらい（そしておそらくもっと）、OOPでは悪いコードを作成する方法があります。Metaquotesが提供する "標準ライブラリ "を見てください。
OOP対手続き型は無駄で終わりのない議論です。もっと有益なのは、「質の高いコードを作るにはどうしたらいいか？OOPの有無、手続き型の有無、どのようなプログラミングパラダイムを使うか使わないか」です。もし、あなたのニーズが木造の家を建てることであるなら、レンガは必要ないでしょう。
すべてはプロシージャルで理論的には可能です。実用的ではないんです。
レンガは何千何万という砂の粒子でできているので、レンガがなくても砂だけで家を建てることができます。
でも、レンガがあっても誰も挑戦しない。
飛行機は、翼、車輪、座席、コンピュータなど、既製の部品で作られています。最終的には金属かプラスチックかガラスでできています。しかし、誰も純粋なガラス、プラスチック、金属から飛行機を作ろうとはしません。
一般的な議論について（Alainと他の人への返答として）。CArrayObj（オブジェクトの配列）を見てみましょう。これだけで、OOのパワーとは何か（これよりはるかに大きなものです）を答えるのに十分です。これはどんなオブジェクトの配列でも格納することができます - 例えば指標のような。
そして、これらの異なるインジケータのために複雑なことをするのは、まったく労力がかかりません。そして、これに新しい力を加えたい場合、例えばインジケータのバッファが クロスしたときにそれを知りたい場合、CIndicatorにメソッドを置くだけでいいのです。といった具合です。プロシージャルでどうやるんだ？
そしてこれは、ストラテジー、トレード、ディール、シグナルなど、あらゆる局面で行うことができます。
あなたの例では、OOコードを書いてコンパイルをクリックすると、マシン・コードが生成されます。しかし、このマシンコードは手続き型なのか、そうでないのか？私は本当に答えを知らない、ここで誰か知っていますか？もし、機械語コードが手続き的であるなら、OOはより高度な言語と呼ぶことができるでしょう、それはコーディングを容易にするだけで、特別なものではありません。そこで質問ですが、元コードはプロデッショナルなのでしょうか、そうでないのでしょうか？