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

新しいコメント
 
Andrei:
内部MT変数の話ではなく、分離した内部オブジェクト変数の話なので、デバッグやコード作成中にその値を読み取る可能性を防いでください...。

それは、EAをデバッグするときに、MTの内部変数が必要ではないか、ということです。

同様に、今回のトレードプロセッサー・オブジェクトでも、例えばTSの発注方法をデバッグする場合、なぜトレードプロセッサーの内部変数にアクセスできるのでしょうか。

 
Комбинатор:
アンドレイはピーターやサンサニッチよりもさらに臨床的なんだ、時間の無駄だよ。

若い人たちに教えてあげないといけない。

それに、相手の言うことには合理的な理由があるのかもしれない。もし私が、例えばピーターのような記憶力を持っていたら、PLOにも迷惑をかけないかもしれない。

 
George Merts:

他の場所でも同じです。何らかのデータが必要な場合、このブロックは適切なインターフェイスを提供しなければなりません。

そういうことなんだ...。必要な変数の値を見るだけでなく、その変数に適切なインタフェースを取り付け、それを元に戻す方法を考えなければならない。:)

プログラミングのマゾヒストのための活動のようだ :)

 
Andrei:

そうですね...何が入っているのか気になりますよね :)適切なプログラミング言語があり、最小限のジェスチャーでデバッグやコード作成を容易にすることですが、ここでは全く逆の状況になっています...。

これは「逆の状況」ではない。確かにOOPは余計な手間がかかる。しかし、それを補って余りあるほど、サポートやシステム改変の利便性が高いのです。

ここでまた、トレードプロセッサーの話に戻りますが、これは多くのTSに書かれており、使われています。TSから内部を隔離し、仮想的なインターフェイスだけで作業することで、その中にどんな変数があり、それが何に等しいかを考えなくて済むからだ。エラーが検出された場合、そのエラーはプロセッサ内部に存在するため、実クラス内部で修正する必要があり、TSクラスには影響しない。TS自体にエラーがある場合、トレードプロセッサーの変数には影響しません。

カプセル化は、実はとても便利な技術なのです。

 
Andrei:

そうですね...一体何が入っているのか、気になって仕方ないですよね :)適切なプログラミング言語があり、最小限のジェスチャーでデバッグやコード作成を容易にすることですが、ここでは全く逆の状況になっています...。


デバッグを容易にするのは、各クラスがそれぞれの変数に責任を持つという、各クラスの責任分担にほかならない。他のクラスには、自分たちの価値観を変える権利はないのです。その結果、ほとんどの問題はコンパイルの段階ですでに解消されている。また、プログラムのどこからでも変数にアクセスできる のは、1隻の船に何十ものハンドルがあるのと同じことです。

 
George Merts:

若い人たちに教えてあげないといけない。

また、相手の言うことには、もしかしたら合理的な根拠があるのかもしれません。例えば、私がピーターのような記憶力を持っていたら、私もわざわざOOPを使うことはないでしょう。

1.OOPを活用 することで、顧問先の収益性はどの程度向上したのでしょうか？

2.OOPの使用により、顧問先の収益性はどの程度低下したのでしょうか？

 
Andrei:

そういうことなんだ...。必要な変数の値を見るだけでなく、その変数に適切なインタフェースを取り付け、それを元に戻す方法を考えなければならない。:)

プログラミングのマゾヒストのための活動のようだ :)

ほら、上のほうでピーターが見せたのは、彼の構造物の一つで、一番大きなものではないんです。

簡単にわかるかな？

まさにこの「マゾヒズム」があるからこそ、まず、作業コードに手を入れず、台無しにしないことができるのです。そして第二に、プログラムの対応するブロックに必要なデータを用意できるように、システム構造を即座に設計 できることです。

たしかに、ふと気がつくと、必要なデータがほとんど手に入らないという事態はありますね。それらは、いくつかの仮想インターフェースの背後に隠されています。しかし、このような事態は、もともとこのデータの送信を想定していなかったという、システム設計の誤りを明確に示しています。この状況は実に不愉快です。急遽、インターフェイスを追加する形で「松葉杖」を作るか、システム全体を再構築するか、どちらかですね。 まあ...。そのため、プログラマーはシステムアーキテクチャをより慎重に考えなければならないという動機がある。

 
Andrei:
感情や反射神経を抑え、議論の本質をより具体的にしていたら--。:)

もうこの議論に中身はない。根本的にはぐらかし、鈍感なふりをする。

もしモデレーターが、このスレッドのトピックやプログラミング一般に無関係だとして、最後の数ページをシャットダウンするなら、私が彼の行動を支持するのは稀なケースでしょう。

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

1.OOPを 使うことで、EAの収益性はどの程度向上しましたか？

2.OOPの活用により、アドバイザーの故障率はどの程度減少しましたか？

1.いくらというわけではありません。収益性はOOPに依存しない。

2.私見では、一桁（10倍）違う。しかし、OOPから得られる主なものは、コードサポートにあります。今は、1年以上前に書いたコードを理解するのがとても速くなりました。私は、初期のANSI Cのプログラムを純粋に手続き型で理解したことをよく覚えています。もっと大変でした。

 
Ihor Herasko:

デバッグを容易にするのは、各クラスがそれぞれの変数に責任を持つという、各クラスの責任分担にほかならない。他のクラスには、自分たちの価値観を変える権利はないのです。その結果、ほとんどの問題はコンパイルの段階ですでに解消されている。また、プログラムのどこからでも変数にアクセスできる のは、船の舵取りを12個に例えることができる。


なぜ、私が仕事でそのようなことに遭遇したことがないのか、理解できない。なぜ、それほど大きくないプログラムで、一人の開発者が変数アクセスの区切り方を問題にするのでしょうか？100人の開発者がいて、それぞれが100の機能を書いている。理論的には、発明できるかもしれません。しかし、実質的にプログラミングがOOPに進化して約40年、山のようなコードが書かれ、そのようなものを聞いたことがないのです。

1...282930313233343536373839404142...48
新しいコメント