OOPと手続き型プログラミングの比較 - ページ 37

 
Andrei:

クラスは内部変数しか持たず、入出力変数を持たない...。外界との接触がなく、自分の汁で沸騰するような物体を、プログラミングに使うというのは、どこで見たことがあるのでしょうか。


+100

 

この議論を見ていると、最近彼らが見せてくれたビデオを思い出しますね :)


 
Andrei:

このクラスは内部変数しか持たず、入出力はありません...。外界と接触せず、自分の汁で調理する、そんなモノがプログラミングに使われているのをどこで見たことがありますか?

クラスは、外の世界と対話するためのインターフェイスを持っています。外部ブロックを目的としない「不要なもの」をすべて断ち切ることができるのです。

例えば、私のトレードプロセッサーには変数があり、MT4用のもの、MT5用のもの、両方のプラットフォーム用のものなどがあります。しかし、これらの変数はすべて、私のTSのどの部分にも全く必要ありません。敬称略、アクセスはできません。TSのすべての部分は、TSの動作に必要な機能のみが定義され、無関係なもの、プラットフォーム依存のもの、「トレード専用」のものは取り除かれたトレードプロセッサの仮想インターフェイスを受け取ります。

これは、トレードポジションと同じです。TSの一部は、トレードポジションに直接アクセスすることはできません。彼らは、オープントレードのコンポーネントの数と各コンポーネントのデータをカウントすることができる仮想インターフェイスを取得することができますのみです。しかし、TSは、それがMT4の注文なのか、MT5のポジションなのか、何を扱っているのかさえわからないのです。全ては彼女に隠されている。TSは、MT4の注文やMT5のポジションを処理するために使用される変数にアクセス できるべきではありませんし、そうではありません。

 
George Merts:

クラスは、外の世界と対話するためのインターフェイスを持っています。外部ブロックを目的としない「余計なもの」をすべて切り捨てることができるのです。

特に、私のトレード・プロセッサーでは、MT4用、MT5用、両方のプラットフォーム用の変数があります。しかし、これらの変数はすべて、私のTSのどの部分にも全く必要ありません。敬称略、アクセスはできません。TSのすべての部分は、TSの動作に必要な機能のみが定義され、不要なもの、すべてのプラットフォーム依存のもの、「取引専用」のものは取り除かれた、取引プロセッサの仮想インターフェースを受け取ります。


具体的に、とてもわかりやすい例を挙げましょう。

1.入力時のコチエ

2.出力に買い/売りのコマンドがある。

3.入力は2つのワイプの交点で出力に変換される。

両者のOOPとその理由は何ですか?

 
СанСаныч Фоменко:

なぜ、端末や言語、そして一般的に、Cp...などのソフトウェア製品に膨大なマニュアルを書いたのだろうか?実際、ドキュメントのないソフトウェア製品はあるのだろうか?それがわからないのは不思議です。


残念ながら、またごちゃ混ぜになっていますね。プログラムのマニュアルはドキュメントではありません。前世紀にはドキュメントを整備し、州の基準に従ったものでした。今、私たちはそのすべてを必要としていません。あとはToRだけです。ドキュメントは、テストケースとクラスのインターフェイスで構成されるようになりました。もちろん、クラスはその名前だけで、何をするのか、何のために使うのかが明確になるように命名されている。

 
Ihor Herasko:

残念ながら、あなたはまたしても用語を混同しています。プログラムマニュアルは文書ではありません。前世紀は文書があり、GOSTなどにも従っていたのです。今となっては不要なものばかりです。あとはToRだけです。ドキュメントは、テストケースとクラスのインターフェイスで構成されるようになりました。そしてもちろん、クラスはその名前で、何をするのか、何のために使うのかがわかるような名前になっています。

ドキュメントは前世紀に保管し、州の基準に従ったりしていました。今となっては不要なものばかりです。

ここは絶対同意!まともなこと書かないから。

昔からToRはありました。しかし、TTでアルゴリズムが完全に定義できるような単純なプログラムは、前世紀には書かれておらず、現在でもまともな人は書いていない。

コンパイラを開発するときの「テストケースとクラスインターフェース」とは? 数学的アルゴリズムをプログラミングするときの「テストケースとクラスインターフェース」とは?



PS.

昔はパールス用のルビがあった。

これが入っているんです。

プログラムマニュアルは文書ではありません。

 
СанСаныч Фоменко:

具体的な例を挙げて、非常にわかりやすく説明しましょう。

1. 入力が商である

2.出力は、売買コマンドです。

3.入力は2つのワイプの交点で出力に変換される。

両者のOOPとその理由は何ですか?

単純なことなんですけどね。

入力ジェネレーターがあります。エキスパートアドバイザーは、データプロバイダのインターフェース、トレードポジションのインターフェース、トレードプロセッサーのインターフェースを要求します。 そして、ワンドの2つのインターフェースがデータプロバイダに要求されます。

OnTick()が呼び出されると、同じ関数がインプットジェネレータから呼び出されます。入力ジェネレーターは、波打つインターフェースを見て、その過去の値を比較する。クロスオーバーを検出すると、取引ポジションのインターフェイスが表示されます。もし、ポジションを持っていないと判断された場合、トレード・プロセッサー・インターフェースを呼び出し、買いまたは売りの機能を実行させます。ポジションがあることを確認したら、もしポジションが必要な方向であれば、何もしません。

ジェネレーターは、ワイプの計算、取引ポジションの取得、MT4での注文の開始、MT5でのポジションの取得のいずれも、変数にアクセスしないことに留意する必要があります。デートプロバイダーは、リクエストされたワイプしか知らない。ティックごとに再計算して更新しているのだ。誰もそのことを知らないのに。貿易処理業者 - インターフェースを通じて送られてくる指示を実行するだけで、それが誰からの指示なのかさえ分からない。エキスパートアドバイザー - 刻み目ごとに取引位置を更新し、誰がそれを必要とし、このブロックの内部を持っているかを調べることなく、要求されたインターフェイスにそれを与える。すべてのブロックは分離され、あらかじめ定義されたインターフェースを通じてのみ通信が行われます。

 
СанСаныч Фоменко:

具体的な例を挙げて、非常にわかりやすく説明しましょう。

1. 入力が商である

2.出力は、売買コマンドです。

3.入力は2つのワイプの交点で出力に変換される。

両者のOOPとその理由は何ですか?

/// применение  ООП для элементарных задач (фактически весь код)

OnInit(){

Series FAST_MA=MA(...);

Series SLOW_MA=MA(...);

OnCrossUp(FAST_MA,SLOW_MA,Buy);

OnCrossDn(FAST_MA,SLOW_MA,Sell);

}

しかし、鍛え上げられたライブラリの中で、それ自体がOOPなのです。簡単に、シンプルに書くために、そして同時に、すべてをデバッグできるようにするために行われます。引用符のソース "と "注文の実行者"、 "時系列"、 "指標 "と他のものの多くのインタフェースがありますが、この短いコードは、すべてのグリッチとnastiesと、実際の市場の厳しい条件のために準備されています。

簡単な移動で、任意の商(合成)を取るか、別のシンボルで実行するか...または単に別のExpert Advisor(そしてこれはOOPの利点である、内部の複雑さ、および応用問題は少し努力を必要とする)をコマンドします。

 
George Merts:

単純なことなんですけどね。

入力ジェネレーターがあります。エキスパートアドバイザーは、データプロバイダーのインターフェース、トレードポジションのインターフェース、トレードプロセッサーのインターフェースを要求します。 そして、データプロバイダーから2つのワゴンのインターフェースを要求します。

OnTick()が呼び出されると、同じ関数がインプットジェネレーターから呼び出されます。入力ジェネレーターは、波打つインターフェースを見て、その過去の値を比較する。クロスオーバーを検出すると、取引ポジションのインターフェイスが表示されます。もし、ポジションを持っていないと判断された場合、トレード・プロセッサー・インターフェースを呼び出し、買いまたは売りの機能を実行させます。ポジションがあることを確認したら、もしポジションが必要な方向であれば、何もしません。

ジェネレーターは、ワイプの計算、取引ポジションの取得、MT4での注文の開始、MT5でのポジションの取得のいずれも、変数にアクセスしないことに留意する必要があります。デートプロバイダーは、リクエストされたワイプしか知らない。ティックごとに再計算して更新しているのだ。誰もそのことを知らないのに。貿易処理業者 - インターフェースを通じて送られてくる指示を実行するだけで、それが誰からの指示なのかさえ分からない。エキスパートアドバイザー - 刻み目ごとに取引位置を更新し、誰がそれを必要とし、このブロックの内部を持っているかを調べることなく、要求されたインターフェイスにそれを与える。すべてのブロックは分離され、あらかじめ定義されたインターフェースを通じてのみ通信が行われます。


驚きです。

私が疑問に思ったのは、現代のプログラミングにおいて、もっと唐突に卵レベルの問題を混乱させる可能性はないのだろうか、ということです。

 
Maxim Kuznetsov:

/// применение  ООП для элементарных задач (фактически весь код)

OnInit(){

Series FAST_MA=MA(...);

Series SLOW_MA=MA(...);

OnCrossUp(FAST_MA,SLOW_MA,Buy);

OnCrossDn(FAST_MA,SLOW_MA,Sell);

}

しかし、OOPそのものは開発されたライブラリの中にあります。簡単に、シンプルに書けるように作られており、その時点ですべてが微調整されているのです。quote source" と "order executor" インターフェース、"timeseries", "indicators" と他の多くのものがあります... しかし、この短いコードは、すべての不具合や厄介なものを含む、ハードな実際の市場の状況に対応しています。

簡単な移動で、任意の商(合成)を取るか、別のシンボルで実行するか...または単に別のExpert Advisor(そしてこれはOOPの利点である、内部の複雑さ、および応用問題は少し努力を必要とする)をコマンドします。


私のOnInit()もほぼ同じで、十数行 です...

それで?