OOPと手続き型プログラミングの比較 - ページ 25 1...181920212223242526272829303132...48 新しいコメント forexman77 2017.08.14 11:42 #241 1.記事に基づいていくつかのインクルードクラスを作った。ただ、なぜ呼び出し可能な関数を 含むインクルードファイルを作る代わりに、クラスを使用するのかが理解できません。2.質問があるのですが、最適化の速度を上げるためには、インクルードファイルを複数に分けるのが良いのでしょうか、それとも全てを一つにまとめるのが良いのでしょうか？3.ExpertAdvisor内ではなく、includeファイルでインジケータを呼び出すと、最適化速度が速くなるような気がするのですが......？ Georgiy Merts 2017.08.14 11:57 #242 forexman77:1.記事に基づいていくつかのインクルードクラスを作った。ただ、なぜ呼び出し可能な関数を 含むインクルードファイルを作る代わりに、クラスを使用するのかが理解できません。2.質問があるのですが、最適化の速度を上げるためには、インクルードファイルを複数に分けるのが良いのでしょうか、それとも全てを一つにまとめるのが良いのでしょうか？3.EA内ではなく、インクルードファイルでインジケータを呼び出すと最適化速度が速くなる気がするのですが......？1.クラスは、ポリモーフィズムが必要な場合、すなわち、類似の目的を持つ異なる関数を呼び出す場合に必要となります。最も単純な例は、あるブロックが注文へのポインタを受け取り、そのチケットを取得する必要がある場合です。実注文と履歴注文、MT4とMT5を考慮し、4種類の機能を搭載しています。 手続き的アプローチの場合 - オーダーの種類に応じて必要な関数を呼び出す特定のスイッチを用意する必要があります。OOPの場合 - チケットを取得するための関数を呼び出すだけです。必要な関数が自動的に呼び出されます。しかし、OOPの場合、クラスや関数の階層を定義するための下準備が必要です。2.用意された実行モジュールに従って最適化を行う。したがって、ソースコードがファイルに分割されているか、1つの大きなファイルに詰め込まれているかは問題ではありません。ファイルへの分割は、あくまでもプログラマーが都合の良いように選択するものである。 3.全く違いはありません。個人的には、インジケータを呼び出すことはなく、Expert Advisorの中で直接値を計算することを好んでいます。 forexman77 2017.08.14 12:08 #243 George Merts:1.クラスは、ポリモーフィズム（類似の目的を持つ異なる関数を呼び出すこと）が必要な場合に必要となります。最も単純な例では、ブロックが注文へのポインタを受け取り、そのチケットを取得する必要があります。実注文と履歴注文、MT4とMT5を考慮し、4種類の機能を搭載しています。 手続き的アプローチの場合 - オーダーの種類に応じて必要な関数を呼び出す特定のスイッチを用意する必要があります。OOPの場合 - チケットを取得するための関数を呼び出すだけです。必要な関数が自動的に呼び出されます。しかし、OOPの場合、クラスや関数の階層を定義するための下準備が必要です。2.用意された実行モジュールに従って最適化を行う。したがって、ソースコードがファイルに分割されていようが、1つの大きなファイルに詰め込まれていようが関係ないのです。ファイルに分割するのは、すべてプログラマーが自分で選択することです。 3.まったく違いがないのです。私自身はインジケータを呼び出すことはなく、Expert Advisorの中で直接値を計算することを好んでいます。 なるほど。ありがとうございます。もちろん、多くのコードをファイルやクラスでラップして、Expert Advisor に数行だけ残すことができるので、すべてが便利です。別に、コードの断片にエラーがないか、新しいものを追加するなどのチェックがしやすくなります。特にμl5ではコードが分かりやすくなります。 Nikolai Semko 2017.08.14 14:29 #244 Реter Konow: なぜ、地元の園芸家が確信犯的に自分の家の敷地内の木の下に穴を開けてしまうのか、その理由だけは不明である（笑)。その敷地内に家も建てることにしたのだろう。何がいけないんですか？そう、もちろん、今人類が享受している大きな運河の多くも、シャベルで掘っているのだ。しかし、当時はまだショベルカーがない時代。では、ショベルカーがある今、なぜシャベルで穴を掘るのか。 Реter Konow 2017.08.14 16:17 #245 Nikolai Semko:その敷地内に家も建てることにしたのだろう。何がいけないんですか？そう、もちろん、今人類が享受している大きな運河の多くも、シャベルで掘っているのだ。しかし、当時はまだショベルカーがない時代。では、ショベルカーがある今、なぜシャベルで穴を掘るのか。重要なのは、あなたの言う「シャベル」は、私の言う「手続き型」プログラミングとは全く違うということです。全く話にならない、と言われそうですが。私が言いたいのは、ここで一部の人が使っている問題解決の方法自体が非常に弱いので、ショベルカーもシャベルも、どちらも効果的に使わなければ意味がないということです。プロフェッショナリズムの問題であり、その不在はツールでは代替できない...。また、プロフェッショナリズムがあれば、プロシージャルの手法で山を作ることも可能です。私を信じてください。 Nikolai Semko 2017.08.14 16:33 #246 Реter Konow: 重要なのは、あなたが言う「ショベルウェア」は、私が言う「手続き型」プログラミングとは全く違うということです。全く話にならない、と言われそうですが。私が言いたいのは、ここで一部の人が使っている問題解決の方法自体が非常に弱いので、ショベルカーもシャベルも、どちらも効果的に使わなければ意味がないということです。プロフェッショナリズムの問題であり、その不在はツールでは代替できない...。また、プロフェッショナリズムがあれば、プロシージャルの手法で山を作ることも可能です。私を信じてください。異論はありませんが、私は掘削のプロになるより、ショベルカーのプロになることにエネルギーを使いたいですね。また、「手続き型」プログラミングというのが何を指すのかわかりませんが、OOPは手続き型プログラミングの進化系であることは知っています。 Maxim Kuznetsov 2017.08.14 16:40 #247 forexman77:1.記事に基づいていくつかのインクルードクラスを 作った。ただ、なぜ 呼び出し可能な関数を 含むインクルードファイルを作成する代わりにクラスを使用 するのかが理解できないのですが？2.質問があるのですが、最適化の速度を上げるためには、インクルードファイルを複数に分けるのが良いのでしょうか、それとも全てを一つにまとめるのが良いのでしょうか？3.ExpertAdvisor内ではなく、includeファイルでインジケータを呼び出すと、最適化速度が速くなるような気がするのですが......？謎は解けました。記事です :-) コードのためのコードがあり、記事そのもののボリュームがあります...。「食前は新聞を読むな」:-) Nikolai Semko 2017.08.14 16:45 #248 Реter Konow: 重要なのは、あなたが言う「ショベルウェア」は、私が言う「手続き型」プログラミングとは全く違うということです。全く話にならない、と言われそうですが。私が言いたいのは、ここで一部の人が使っている問題解決の方法自体が非常に弱いので、ショベルカーもシャベルも、どちらも効果的に使わなければ意味がないということです。プロフェッショナリズムの問題であり、その不在はツールでは代替できない...。また、プロフェッショナリズムがあれば、プロシージャルの手法で山を作ることも可能です。私を信じてください。一般的に、ピーターさんは、シャベルで掘った自分のピットと、ショベルカーで掘った隣のピットを見ているような気がするのですが、いかがですか？見比べると、トレンチの方が大きく、端が平らになっていることがわかります。そして、シャベルで掘ったほうがいいという結論に至るわけです。ショベルカーで掘ることを覚えたら......想像できますか？と、シャベルで縁を均すことができます。 Реter Konow 2017.08.14 16:53 #249 Nikolai Semko: そして、一般的にピーターさんは、シャベルで掘った自分の穴と、ショベルカーで掘った隣の穴を見ているような気がするのですが、いかがですか？見比べると、トレンチの方が大きく、端が平らになっていることがわかります。そして、シャベルで掘ったほうがいいという結論に至るわけです。ショベルカーで掘ることを覚えたら......想像できますか？...そして、シャベルでエッジを均すことができます。ニコライ 道具で例えると、僕は全然スコップで掘っていないんですよ。別のツールで、もっとクールなものです。まだ呼び名が決まっていませんが、ショベルカーに追いつけないということは十分あり得ます。未来が教えてくれる...一般的に、私は道具としてのショベルカーを尊敬していますが、それを勉強する時間はなかったのです。もう1つのアイデアが実現したのです）。 Nikolai Semko 2017.08.14 17:31 #250 Реter Konow:ニコライ 道具で例えると、僕は全然スコップで掘っていないんですよ。別のツールで、もっとクールなものです。まだ呼び名は決まっていませんが、ショベルカーにもついていけない可能性は十分にあります。未来が教えてくれる...一般的に、私は道具としてのショベルカーを尊敬していますが、それを勉強する時間はなかったのです。もう1つのアイデアが実現したのです）。 それなら、テーマも違って聞こえるはずです。プログラミングの新しいツールキット」とか「新しいプログラミングパラダイム」とか......。 OOPよりかっこいいものを作ったというのが本当なら、有名になったら自分のものにサインをしてくれるのでしょうか？ 1...181920212223242526272829303132...48 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
1.記事に基づいていくつかのインクルードクラスを作った。ただ、なぜ呼び出し可能な関数を 含むインクルードファイルを作る代わりに、クラスを使用するのかが理解できません。
2.質問があるのですが、最適化の速度を上げるためには、インクルードファイルを複数に分けるのが良いのでしょうか、それとも全てを一つにまとめるのが良いのでしょうか？
3.ExpertAdvisor内ではなく、includeファイルでインジケータを呼び出すと、最適化速度が速くなるような気がするのですが......？
1.記事に基づいていくつかのインクルードクラスを作った。ただ、なぜ呼び出し可能な関数を 含むインクルードファイルを作る代わりに、クラスを使用するのかが理解できません。
2.質問があるのですが、最適化の速度を上げるためには、インクルードファイルを複数に分けるのが良いのでしょうか、それとも全てを一つにまとめるのが良いのでしょうか？
3.EA内ではなく、インクルードファイルでインジケータを呼び出すと最適化速度が速くなる気がするのですが......？
1.クラスは、ポリモーフィズムが必要な場合、すなわち、類似の目的を持つ異なる関数を呼び出す場合に必要となります。最も単純な例は、あるブロックが注文へのポインタを受け取り、そのチケットを取得する必要がある場合です。実注文と履歴注文、MT4とMT5を考慮し、4種類の機能を搭載しています。
手続き的アプローチの場合 - オーダーの種類に応じて必要な関数を呼び出す特定のスイッチを用意する必要があります。OOPの場合 - チケットを取得するための関数を呼び出すだけです。必要な関数が自動的に呼び出されます。しかし、OOPの場合、クラスや関数の階層を定義するための下準備が必要です。
2.用意された実行モジュールに従って最適化を行う。したがって、ソースコードがファイルに分割されているか、1つの大きなファイルに詰め込まれているかは問題ではありません。ファイルへの分割は、あくまでもプログラマーが都合の良いように選択するものである。
3.全く違いはありません。個人的には、インジケータを呼び出すことはなく、Expert Advisorの中で直接値を計算することを好んでいます。
1.クラスは、ポリモーフィズム（類似の目的を持つ異なる関数を呼び出すこと）が必要な場合に必要となります。最も単純な例では、ブロックが注文へのポインタを受け取り、そのチケットを取得する必要があります。実注文と履歴注文、MT4とMT5を考慮し、4種類の機能を搭載しています。
手続き的アプローチの場合 - オーダーの種類に応じて必要な関数を呼び出す特定のスイッチを用意する必要があります。OOPの場合 - チケットを取得するための関数を呼び出すだけです。必要な関数が自動的に呼び出されます。しかし、OOPの場合、クラスや関数の階層を定義するための下準備が必要です。
2.用意された実行モジュールに従って最適化を行う。したがって、ソースコードがファイルに分割されていようが、1つの大きなファイルに詰め込まれていようが関係ないのです。ファイルに分割するのは、すべてプログラマーが自分で選択することです。
3.まったく違いがないのです。私自身はインジケータを呼び出すことはなく、Expert Advisorの中で直接値を計算することを好んでいます。
なるほど。ありがとうございます。もちろん、多くのコードをファイルやクラスでラップして、Expert Advisor に数行だけ残すことができるので、すべてが便利です。
別に、コードの断片にエラーがないか、新しいものを追加するなどのチェックがしやすくなります。特にμl5ではコードが分かりやすくなります。
なぜ、地元の園芸家が確信犯的に自分の家の敷地内の木の下に穴を開けてしまうのか、その理由だけは不明である（笑)。
その敷地内に家も建てることにしたのだろう。何がいけないんですか？
そう、もちろん、今人類が享受している大きな運河の多くも、シャベルで掘っているのだ。しかし、当時はまだショベルカーがない時代。では、ショベルカーがある今、なぜシャベルで穴を掘るのか。
その敷地内に家も建てることにしたのだろう。何がいけないんですか？
そう、もちろん、今人類が享受している大きな運河の多くも、シャベルで掘っているのだ。しかし、当時はまだショベルカーがない時代。では、ショベルカーがある今、なぜシャベルで穴を掘るのか。
重要なのは、あなたの言う「シャベル」は、私の言う「手続き型」プログラミングとは全く違うということです。全く話にならない、と言われそうですが。私が言いたいのは、ここで一部の人が使っている問題解決の方法自体が非常に弱いので、ショベルカーもシャベルも、どちらも効果的に使わなければ意味がないということです。
プロフェッショナリズムの問題であり、その不在はツールでは代替できない...。
また、プロフェッショナリズムがあれば、プロシージャルの手法で山を作ることも可能です。私を信じてください。
重要なのは、あなたが言う「ショベルウェア」は、私が言う「手続き型」プログラミングとは全く違うということです。全く話にならない、と言われそうですが。私が言いたいのは、ここで一部の人が使っている問題解決の方法自体が非常に弱いので、ショベルカーもシャベルも、どちらも効果的に使わなければ意味がないということです。
プロフェッショナリズムの問題であり、その不在はツールでは代替できない...。
また、プロフェッショナリズムがあれば、プロシージャルの手法で山を作ることも可能です。私を信じてください。
異論はありませんが、私は掘削のプロになるより、ショベルカーのプロになることにエネルギーを使いたいですね。
また、「手続き型」プログラミングというのが何を指すのかわかりませんが、OOPは手続き型プログラミングの進化系であることは知っています。
1.記事に基づいていくつかのインクルードクラスを 作った。ただ、なぜ 呼び出し可能な関数を 含むインクルードファイルを作成する代わりにクラスを使用 するのかが理解できないのですが？
2.質問があるのですが、最適化の速度を上げるためには、インクルードファイルを複数に分けるのが良いのでしょうか、それとも全てを一つにまとめるのが良いのでしょうか？
3.ExpertAdvisor内ではなく、includeファイルでインジケータを呼び出すと、最適化速度が速くなるような気がするのですが......？
謎は解けました。記事です :-) コードのためのコードがあり、記事そのもののボリュームがあります...。「食前は新聞を読むな」:-)
重要なのは、あなたが言う「ショベルウェア」は、私が言う「手続き型」プログラミングとは全く違うということです。全く話にならない、と言われそうですが。私が言いたいのは、ここで一部の人が使っている問題解決の方法自体が非常に弱いので、ショベルカーもシャベルも、どちらも効果的に使わなければ意味がないということです。
プロフェッショナリズムの問題であり、その不在はツールでは代替できない...。
また、プロフェッショナリズムがあれば、プロシージャルの手法で山を作ることも可能です。私を信じてください。
一般的に、ピーターさんは、シャベルで掘った自分のピットと、ショベルカーで掘った隣のピットを見ているような気がするのですが、いかがですか？見比べると、トレンチの方が大きく、端が平らになっていることがわかります。そして、シャベルで掘ったほうがいいという結論に至るわけです。ショベルカーで掘ることを覚えたら......想像できますか？と、シャベルで縁を均すことができます。
そして、一般的にピーターさんは、シャベルで掘った自分の穴と、ショベルカーで掘った隣の穴を見ているような気がするのですが、いかがですか？見比べると、トレンチの方が大きく、端が平らになっていることがわかります。そして、シャベルで掘ったほうがいいという結論に至るわけです。ショベルカーで掘ることを覚えたら......想像できますか？...そして、シャベルでエッジを均すことができます。
ニコライ 道具で例えると、僕は全然スコップで掘っていないんですよ。別のツールで、もっとクールなものです。まだ呼び名が決まっていませんが、ショベルカーに追いつけないということは十分あり得ます。未来が教えてくれる...
一般的に、私は道具としてのショベルカーを尊敬していますが、それを勉強する時間はなかったのです。もう1つのアイデアが実現したのです）。
ニコライ 道具で例えると、僕は全然スコップで掘っていないんですよ。別のツールで、もっとクールなものです。まだ呼び名は決まっていませんが、ショベルカーにもついていけない可能性は十分にあります。未来が教えてくれる...
一般的に、私は道具としてのショベルカーを尊敬していますが、それを勉強する時間はなかったのです。もう1つのアイデアが実現したのです）。
OOPよりかっこいいものを作ったというのが本当なら、有名になったら自分のものにサインをしてくれるのでしょうか？