PLOの諸経費 - ページ 3 1234567 新しいコメント Andrei01 2017.07.06 14:25 #21 George Merts:1.例えば、オブジェクトの配列が必要だとします。 問題は、オブジェクトの追加や削除、ソートなどの動作を変更する必要がある場合です。OOPでは、ポインタ配列の適切なサポートとそれを使った作業は、ベースとなるオブジェクトに内包されています。実際に配列に含まれる子孫オブジェクトを変更しても、何も影響はありません。手続き型では、配列に含まれる実際のオブジェクトを変更する場合、少なくともオブジェクトのサイズの変更を考慮しなければならないため、通常はより多くの場所に影響を及ぼします。そうすると、より簡単にエラーが発生します。 2.クロスプラットフォーム - また、OOPスタイルで整理する方がはるかに便利です。要求があったとき、例えば、取引ポジション - 私たちはインターフェイスを取得し、それは我々が働くどのようなプラットフォームに関係ありません - インターフェイスは、すべての注文（MT4用）またはポジション（MT5）のデータのすべてを取得することができ、仮想機能を 提供し、ビューの専門家の観点から - そこに違いはないです。Expert Advisor は、どのプラットフォームで動作するかを知る必要はありません。3.さて、「手続き型プログラミングの仕上げ」とは、「オブジェクト-手続きを書く」こと、つまり、データと手続きの間に何らかのリンクを作り、それがOOPのオブジェクトを表すということです。4.そして、例えば、何種類ものオーダーがあり、それらは共通する部分が多い。COrderInfoというオブジェクトを作り、それを基本オブジェクトとし、その継承者がさまざまな種類のオーダーを表現するのが合理的だろう。その際、トレードプロセッサー（私はCTradeProcessorクラスを持っています）は、渡されたその注文を、その注文の処理に必要な手続きによって、自動的に正確にサポートすることになります。 5.クロスリンクが少ないところでは、バグを捕らえやすい。これはカプセル化とポリモーフィズムによって確保される。トレードポジションインターフェース（CTradePositionI）を要求し、このポジションを表す実クラス（CMT4PositionInfo、CMT5PositionInfo）との接続はすべてこのインターフェースを介して行われるため、トレードポジションのデータを返す実関数と直接作業するよりもエラー修正が容易になります。1.何のために？なぜ、同じ機能を異なるプラットフォームでコンパイルできないのか？これは、関数のテキストを構造体型でパックすることで、関数をクラスメンバとして扱うこととのアナロジーで、取り扱いを容易にするためのものである。このために、原則としてオブジェクトを作成する必要はない。4.複数のオブジェクトを掛け合わせたり、インターフェースで不要な接続をするのではなく、一つの関数にその設定を行う方が合理的です。5.また、これらのリンクはすべてプログラム化した上で、バグの捕捉が困難なインターフェースなどを通じて追跡する必要があります。この占領は、最初から不必要で無意味なものです。 Georgiy Merts 2017.07.06 15:13 #22 Andrei:1.例えば、何のために？2.なぜ、同じ機能を異なるプラットフォームでコンパイルすると、そのためのインターフェースを作る必要がないのですか？つまり、関数をクラスのメンバとして扱うのと同じように、関数のテキストを構造体の種類でパックして、より便利にアクセスできるようにしたのです。原則として、この目的のためにオブジェクトを作成することはないものとする。4.複数のオブジェクトを掛け合わせたり、インターフェイスで無駄な接続をするよりも、設定で一つの関数を作る方がスマートです。5.また、これらのリンクはすべてプログラム化した上で、バグの捕捉が困難なインターフェースなどを通じて追跡する必要があります。この占領は、最初から不必要で無意味なものです。1.さて、CTradePosition クラスは、基本的に未決済注文のリストです。そして、彼らにとっては、インターフェース、ベースクラス、実際のクラスがあると非常に便利なのです。2.インターフェースは1つだけです。すべてのプラットフォームでまた、OOPの場合、どこで作業しているかということはあまり考えません。プラットフォームに依存するもの、秩序に依存するものを考える必要はない。 また、このパッケージにおけるオブジェクトとファンクションの違いは何でしょうか？つまり、本質的には同じことなんです。オブジェクトの場合、自動コンストラクタ関数も追加されるが、デフォルトでは空である。 4.まさに、この「設定付き単機能」こそが、問題の根源なのです。通常、設定項目が多いからです。そして、彼らは階級階層の異なるところに散らばっているのではなく、まさにこの機能に集中しているのです。これは、コードの理解やエラーの可能性、その検出に非常に有効です。 これはまさにOOPの主な利点で、すべての機能は異なる階層レベルのオブジェクトに「分散」されており、その一部または全部を扱うときに、他のものが干渉することがありません。一方、設定付きの単機能では、たとえ余分な機能があっても、常にすべての機能が利用可能です。また、このような単一の関数では、エラーを検出するのが非常に困難であるというデメリットがあります。5. いずれにせよ、これらのリンクは必要であり、プログラムする必要があります - これらは、実際には、単一の機能で同じ設定です。例えば、私の例では、1つの関数でプラットフォームの違い、注文の種類の違い、ポジションの表現の違いなどにアクセスすることができますが、これらすべてを考慮しなければなりません。そして、インターフェイスがあると、すべてが「切り離され」、インターフェイスで定義されたものだけが考慮されることになります。 それがカプセル化のポイントであり、あるブロックのコードから別のブロックへのアクセスを制限することなのです。それに対して、あなたは、この機能にアクセスできる誰もが最大の可能性を持つように、「最大の設定を持つ1つの大きなユニバーサル機能」を持つことを提案しています。正しい方法は、プログラムのあるブロックが他のブロックの機能を必要とする場合、そのブロックはその機能だけを持ち、それ以上の機能は持たないようにすることです。 これが、より安定した、エラーのないコードの鍵となります。 Andrei01 2017.07.06 15:22 #23 George Merts:1.さて、CTradePosition クラスは、基本的に未決済注文のリストです。オーダーは様々で、そのためにインターフェース、ベースクラス、実クラスがあると非常に便利です。また、注文を構造体の配列で保持すること、MT4で実装されている方法で何が問題なのでしょうか？ Georgiy Merts 2017.07.06 15:26 #24 Andrei:注文を構造体の配列で保持したり、MT4で実装されているようにすることの何が問題なのでしょうか？ なぜなら、各ユーザーはこのアレイにアクセスする際に、あまりにも多くの権限を持ち、不必要な情報を持ちすぎるからです。 私が思うに、正しいやり方は、ユーザーが必要とする機能の一部だけを提供すること、つまり、注文にアクセスするために事前に合意したインターフェースを使用することです。 Andrei01 2017.07.06 15:31 #25 George Merts:この配列にアクセスする際に、各ユーザーの権限が多すぎること、不必要な情報が多すぎること。 私が思うに、正しいやり方は、ユーザーが必要とする機能の一部だけを提供すること、つまり、注文にアクセスするために事前に合意したインターフェースを使用することです。注文のためのデータ型は 自分で作ることができ、インターフェースやオブジェクトなどの余計な工夫は不要で、余計なバグや不安定さを生みません。 Georgiy Merts 2017.07.06 15:50 #26 Andrei:注文のためのデータ型を 自分で作ることができるので、余計なバグや不安定さを生むインターフェースやオブジェクトなどの余計な工夫は必要ありません。私の経験では、必要だと思います。 私は5年ほど前、当時はMT4でこの方法をとりました。(というのも、当時はMT4とMT5でMQLの実装が大きく異なっていたため、インターフェースや継承について悩むのが面倒だったからです）。 その結果、その誤りを理解するに至りました。 これは「知恵」ではなく、極めて妥当な制限、一種の「愚直さ」なのです。何百もの変数がそれぞれ何を担っているかを常に覚えているのであれば、カプセル化は必要ないでしょう。私はこのことを覚えていませんし、プログラムの各ブロックで利用できるエンティティはできるだけ少ない方がいいと思っています。 MT4がOOP化されると同時に、私は自分の開発したものをすべて、インターフェースをベースにした一つの形に変換し始めました。 Andrei01 2017.07.06 16:01 #27 George Merts:1.私の実践では、確かに必要なことだと思います。そのため、その誤謬を理解することができました。 2.私は覚えていませんし、ソフトウェアの各ブロックでアクセスするエンティティはなるべく少ない方がいいと思っています。 1.何のためのもので、何のための誤りなのかが説明されていない。特殊なデータ なので、そこで好きなようにアクセスを設定することができます。この例は明らかに不運な選択です。2.プログラマがアクセスできるようにするためには、あらゆる種類の複雑な回避策を講じなければならず、途中で多くのバグが発生する可能性のある不安定なコードを作成しなければならないからです。運転手がハンドルに触れることを禁止し、その回避策、つまりハンドルの代わりに車を操縦するためのインターフェースを考案するようなものです。 Georgiy Merts 2017.07.06 16:07 #28 Andrei:2.なぜなら、プログラマにアクセスさせるためにあらゆる種類の高度な回避策を講じなければならず、その結果、多くのバグを含む不安定なコードが作成されてしまうからです。運転手がハンドルに触れることを禁止し、その回避策、つまりハンドルの代わりに車を操縦するためのインターフェースを考案するようなものです。いいえ。コードの中のどこでもいいから-その場所で必要なものだけを利用できるようにし、それ以外のものはできれば切り離すこと。 あなたの運転手の場合、駐車中に運転手がハンドルに触れることを禁止するのが妥当ということです。だから、車を停めたままホイールを回そうとはしない。実はその時、ホイールアライメントセンサーなどがホイールに接続されていて、ドライバーがホイールを握ると、その角度の設定に誤差が生じるのだ。 ある瞬間に、その瞬間に必要な機能だけがプログラムに提供され、それ以外はすべて閉じてしまうというものです。私は以前から、これが最も失敗の少ない方法だと確信しています。 Andrei01 2017.07.06 16:19 #29 George Merts:いいえ。コードのどこであろうと、その場所で必要なものだけが利用できるようにし、可能であればそれ以外のものは切り捨てるべきです。 各瞬間に、その時点で必要な機能だけがプログラムから利用でき、それ以外はロックされていなければならないという考え方です。これが一番ミスが少ない方法だと、ずいぶん前に学びました。もちろん、プログラマがコードを書くときに酔っぱらっていて、自分が理解していないコードを大量に書いてしまうかもしれないということを自分でコントロールできていない場合は別ですが、常に何を禁止して何を許可するかで悩むのは、明らかに非常に非論理的な要求です。アル中の酔っぱらいプログラマーがコードのミスを防ぐのに役立つことはないだろうし、シラフの人は最初から必要ないと思う。 Georgiy Merts 2017.07.06 17:54 #30 Andrei:もちろん、プログラマが酔っ払ってコードを書いていて、自分が理解していないコードをたくさん書いてしまうことを自分自身でコントロールできない場合は別ですが、常に何を禁止して何を許可するかを気にすることは、明らかに非常に非論理的な要求です。アルコール中毒の酔っ払いプログラマーがコードのミスを避けるのに役立つことはないと思いますし、シラフの人にはそもそも必要ないでしょう。これは、多くの人が思い当たる、非常に論理的な条件です。必要ないだろーが、まぁ...。は、OOPを使わないでください。 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
1.例えば、オブジェクトの配列が必要だとします。
問題は、オブジェクトの追加や削除、ソートなどの動作を変更する必要がある場合です。OOPでは、ポインタ配列の適切なサポートとそれを使った作業は、ベースとなるオブジェクトに内包されています。実際に配列に含まれる子孫オブジェクトを変更しても、何も影響はありません。手続き型では、配列に含まれる実際のオブジェクトを変更する場合、少なくともオブジェクトのサイズの変更を考慮しなければならないため、通常はより多くの場所に影響を及ぼします。そうすると、より簡単にエラーが発生します。
2.クロスプラットフォーム - また、OOPスタイルで整理する方がはるかに便利です。要求があったとき、例えば、取引ポジション - 私たちはインターフェイスを取得し、それは我々が働くどのようなプラットフォームに関係ありません - インターフェイスは、すべての注文（MT4用）またはポジション（MT5）のデータのすべてを取得することができ、仮想機能を 提供し、ビューの専門家の観点から - そこに違いはないです。Expert Advisor は、どのプラットフォームで動作するかを知る必要はありません。
3.さて、「手続き型プログラミングの仕上げ」とは、「オブジェクト-手続きを書く」こと、つまり、データと手続きの間に何らかのリンクを作り、それがOOPのオブジェクトを表すということです。
4.そして、例えば、何種類ものオーダーがあり、それらは共通する部分が多い。COrderInfoというオブジェクトを作り、それを基本オブジェクトとし、その継承者がさまざまな種類のオーダーを表現するのが合理的だろう。その際、トレードプロセッサー（私はCTradeProcessorクラスを持っています）は、渡されたその注文を、その注文の処理に必要な手続きによって、自動的に正確にサポートすることになります。
5.クロスリンクが少ないところでは、バグを捕らえやすい。これはカプセル化とポリモーフィズムによって確保される。トレードポジションインターフェース（CTradePositionI）を要求し、このポジションを表す実クラス（CMT4PositionInfo、CMT5PositionInfo）との接続はすべてこのインターフェースを介して行われるため、トレードポジションのデータを返す実関数と直接作業するよりもエラー修正が容易になります。
1.何のために？
なぜ、同じ機能を異なるプラットフォームでコンパイルできないのか？
これは、関数のテキストを構造体型でパックすることで、関数をクラスメンバとして扱うこととのアナロジーで、取り扱いを容易にするためのものである。このために、原則としてオブジェクトを作成する必要はない。
4.複数のオブジェクトを掛け合わせたり、インターフェースで不要な接続をするのではなく、一つの関数にその設定を行う方が合理的です。
5.また、これらのリンクはすべてプログラム化した上で、バグの捕捉が困難なインターフェースなどを通じて追跡する必要があります。この占領は、最初から不必要で無意味なものです。
1.例えば、何のために？
2.なぜ、同じ機能を異なるプラットフォームでコンパイルすると、そのためのインターフェースを作る必要がないのですか？
つまり、関数をクラスのメンバとして扱うのと同じように、関数のテキストを構造体の種類でパックして、より便利にアクセスできるようにしたのです。原則として、この目的のためにオブジェクトを作成することはないものとする。
4.複数のオブジェクトを掛け合わせたり、インターフェイスで無駄な接続をするよりも、設定で一つの関数を作る方がスマートです。
5.また、これらのリンクはすべてプログラム化した上で、バグの捕捉が困難なインターフェースなどを通じて追跡する必要があります。この占領は、最初から不必要で無意味なものです。
1.さて、CTradePosition クラスは、基本的に未決済注文のリストです。そして、彼らにとっては、インターフェース、ベースクラス、実際のクラスがあると非常に便利なのです。
2.インターフェースは1つだけです。すべてのプラットフォームでまた、OOPの場合、どこで作業しているかということはあまり考えません。プラットフォームに依存するもの、秩序に依存するものを考える必要はない。
また、このパッケージにおけるオブジェクトとファンクションの違いは何でしょうか？つまり、本質的には同じことなんです。オブジェクトの場合、自動コンストラクタ関数も追加されるが、デフォルトでは空である。
4.まさに、この「設定付き単機能」こそが、問題の根源なのです。通常、設定項目が多いからです。そして、彼らは階級階層の異なるところに散らばっているのではなく、まさにこの機能に集中しているのです。これは、コードの理解やエラーの可能性、その検出に非常に有効です。 これはまさにOOPの主な利点で、すべての機能は異なる階層レベルのオブジェクトに「分散」されており、その一部または全部を扱うときに、他のものが干渉することがありません。一方、設定付きの単機能では、たとえ余分な機能があっても、常にすべての機能が利用可能です。また、このような単一の関数では、エラーを検出するのが非常に困難であるというデメリットがあります。
5. いずれにせよ、これらのリンクは必要であり、プログラムする必要があります - これらは、実際には、単一の機能で同じ設定です。例えば、私の例では、1つの関数でプラットフォームの違い、注文の種類の違い、ポジションの表現の違いなどにアクセスすることができますが、これらすべてを考慮しなければなりません。そして、インターフェイスがあると、すべてが「切り離され」、インターフェイスで定義されたものだけが考慮されることになります。
それがカプセル化のポイントであり、あるブロックのコードから別のブロックへのアクセスを制限することなのです。それに対して、あなたは、この機能にアクセスできる誰もが最大の可能性を持つように、「最大の設定を持つ1つの大きなユニバーサル機能」を持つことを提案しています。正しい方法は、プログラムのあるブロックが他のブロックの機能を必要とする場合、そのブロックはその機能だけを持ち、それ以上の機能は持たないようにすることです。 これが、より安定した、エラーのないコードの鍵となります。
1.さて、CTradePosition クラスは、基本的に未決済注文のリストです。オーダーは様々で、そのためにインターフェース、ベースクラス、実クラスがあると非常に便利です。
また、注文を構造体の配列で保持すること、MT4で実装されている方法で何が問題なのでしょうか？
注文を構造体の配列で保持したり、MT4で実装されているようにすることの何が問題なのでしょうか？
なぜなら、各ユーザーはこのアレイにアクセスする際に、あまりにも多くの権限を持ち、不必要な情報を持ちすぎるからです。
私が思うに、正しいやり方は、ユーザーが必要とする機能の一部だけを提供すること、つまり、注文にアクセスするために事前に合意したインターフェースを使用することです。
この配列にアクセスする際に、各ユーザーの権限が多すぎること、不必要な情報が多すぎること。
私が思うに、正しいやり方は、ユーザーが必要とする機能の一部だけを提供すること、つまり、注文にアクセスするために事前に合意したインターフェースを使用することです。
注文のためのデータ型は 自分で作ることができ、インターフェースやオブジェクトなどの余計な工夫は不要で、余計なバグや不安定さを生みません。
注文のためのデータ型を 自分で作ることができるので、余計なバグや不安定さを生むインターフェースやオブジェクトなどの余計な工夫は必要ありません。
私の経験では、必要だと思います。
私は5年ほど前、当時はMT4でこの方法をとりました。(というのも、当時はMT4とMT5でMQLの実装が大きく異なっていたため、インターフェースや継承について悩むのが面倒だったからです）。 その結果、その誤りを理解するに至りました。 これは「知恵」ではなく、極めて妥当な制限、一種の「愚直さ」なのです。何百もの変数がそれぞれ何を担っているかを常に覚えているのであれば、カプセル化は必要ないでしょう。私はこのことを覚えていませんし、プログラムの各ブロックで利用できるエンティティはできるだけ少ない方がいいと思っています。
MT4がOOP化されると同時に、私は自分の開発したものをすべて、インターフェースをベースにした一つの形に変換し始めました。
1.私の実践では、確かに必要なことだと思います。そのため、その誤謬を理解することができました。
2.私は覚えていませんし、ソフトウェアの各ブロックでアクセスするエンティティはなるべく少ない方がいいと思っています。
1.何のためのもので、何のための誤りなのかが説明されていない。特殊なデータ なので、そこで好きなようにアクセスを設定することができます。この例は明らかに不運な選択です。
2.プログラマがアクセスできるようにするためには、あらゆる種類の複雑な回避策を講じなければならず、途中で多くのバグが発生する可能性のある不安定なコードを作成しなければならないからです。運転手がハンドルに触れることを禁止し、その回避策、つまりハンドルの代わりに車を操縦するためのインターフェースを考案するようなものです。
2.なぜなら、プログラマにアクセスさせるためにあらゆる種類の高度な回避策を講じなければならず、その結果、多くのバグを含む不安定なコードが作成されてしまうからです。運転手がハンドルに触れることを禁止し、その回避策、つまりハンドルの代わりに車を操縦するためのインターフェースを考案するようなものです。
いいえ。コードの中のどこでもいいから-その場所で必要なものだけを利用できるようにし、それ以外のものはできれば切り離すこと。
あなたの運転手の場合、駐車中に運転手がハンドルに触れることを禁止するのが妥当ということです。だから、車を停めたままホイールを回そうとはしない。実はその時、ホイールアライメントセンサーなどがホイールに接続されていて、ドライバーがホイールを握ると、その角度の設定に誤差が生じるのだ。
ある瞬間に、その瞬間に必要な機能だけがプログラムに提供され、それ以外はすべて閉じてしまうというものです。私は以前から、これが最も失敗の少ない方法だと確信しています。
いいえ。コードのどこであろうと、その場所で必要なものだけが利用できるようにし、可能であればそれ以外のものは切り捨てるべきです。
各瞬間に、その時点で必要な機能だけがプログラムから利用でき、それ以外はロックされていなければならないという考え方です。これが一番ミスが少ない方法だと、ずいぶん前に学びました。もちろん、プログラマがコードを書くときに酔っぱらっていて、自分が理解していないコードを大量に書いてしまうかもしれないということを自分でコントロールできていない場合は別ですが、常に何を禁止して何を許可するかで悩むのは、明らかに非常に非論理的な要求です。アル中の酔っぱらいプログラマーがコードのミスを防ぐのに役立つことはないだろうし、シラフの人は最初から必要ないと思う。
もちろん、プログラマが酔っ払ってコードを書いていて、自分が理解していないコードをたくさん書いてしまうことを自分自身でコントロールできない場合は別ですが、常に何を禁止して何を許可するかを気にすることは、明らかに非常に非論理的な要求です。アルコール中毒の酔っ払いプログラマーがコードのミスを避けるのに役立つことはないと思いますし、シラフの人にはそもそも必要ないでしょう。
これは、多くの人が思い当たる、非常に論理的な条件です。
必要ないだろーが、まぁ...。は、OOPを使わないでください。