PLOの諸経費 - ページ 2

[Alexey Volchanskiy]

Andrei:

もちろん、美しいOOPは、リソースと多くのデバッグ時間で賄わなければなりません。OOPは便利なテキストラッパーとして、あるいは実行時の初期化で最小限の使用しか意味をなさない...。実は、OOPは プログラマーの労働時間のコストを上げ、より高度な機器の購入を促すためのマイクロソフト社のマーケティングに過ぎなかったのです。しかも、彼ら自身はバカではなく、すべてのソフトウェアをC言語とアセンブラで書いている。

なんてことはない。

MSのプログラマが直接マシンコードで書いていることは、誰もが知っている。

プログラマーの机の上にはプロセッサーのマシンコードが書かれた本があり、パンチカードにコードを書き込んでいる。

ビル・ゲイツは頭の中でOSをコンパイルできる)

[Andrei01]

Alexey Volchanskiy:

なんということでしょう。

あなたが言ったことの中身について、何か意味のある反論はありますか？

[Andrei01]

Alexey Volchanskiy:

MSのプログラマーが直接マシンコードで書いていることは誰でも知っていることだ

あなたの道化はよくわからない。アセンブリ言語の挿入は、コードのパフォーマンスを向上させるために使用されることが知られている...。

ターミナルでは、dotnetのように大規模な外部ライブラリなしでこのようなコンパクトなファイルを得るのは難しいので、OOPは最小限か全く使われていないと推測できます...。

[Georgiy Merts]

Andrei:
言われたことの本質について、何か意味のある反論はないのでしょうか？

チェックする。アレクセイは、確かに感情的に反応しているだけだ。そして、その反論は要するに次のようなものである。

OOPは、複雑なコードをサポートする必要がある場合に非常に有効です。

確かに、インジケータ-MAにOOPのトリックをすべて適用するのは意味がない。しかし、基本的なクラスを書く場合、たとえMAであっても、OOPアプローチは、通常の手続き的アプローチと少なくとも同じくらい良いものです。

OOPの主な利点は、開発されたオブジェクト構造のサポートによって明らかにされます。カプセル化されているため、オーバーロードされた関数のニュアンスを毎回理解する必要がない場合。ポリモーフィズムに基づくと、コードの再利用 性が非常に高くなる。

OOPの本質は、どんなオブジェクトも常にその性質に関連し、環境との相互作用に一定の規則があるという現実の世界に近いものです。

労働時間のコスト増」については、そんなことはありません。 確かに、OOPスタイルでシステムを設計する場合、手続き指向のアプローチに比べると、少し手間がかかります。しかし、これらの余分なコストは、書かれたコードの保守や修正の利便性で補うことができます。

個人的には、オブジェクトを使わずに、ごく小さな「膝書き」のインジケータを書きます。しかし、それ以上のもの（少なくともクロスプラットフォーム）が必要な場合、私は常にOOPスタイルとオブジェクト・ライブラリの既存のプラクティスを使用することにしています。

[Alexey Volchanskiy]

Andrei:

あなたの道化はよくわからない。アセンブリ言語の挿入は、コードのパフォーマンスを向上させるために使われることは知っているのだが...。

なぜなら、dotnetのような巨大な外部ライブラリがなければ、このようなコンパクトなファイルを得ることは難しいからです。

最近のコンパイラは、平均的な、あるいは優秀なプログラマーよりも何倍も優れた最適化を行っています。まるで前世紀から登場したかのようです。普通のコードでインサートってどういうこと？ドライバはそうですね、アッセブラーを使っていますが、性能のためではなく、ハードウェアとの連携がしやすいから...。

[Andrei01]

George Merts:

1.OOP-ある種の複雑なコードをサポートする必要があるときに、とても役に立ちます。

2.もちろん、インジケータ-MAにすべてのOOPトリックを適用する意味はない。とはいえ、基本的なクラスは、MAであってもOOPアプローチであり、少なくとも通常の手続き型アプローチよりは悪くありません。

3.OOPの主な利点は、開発されたオブジェクト構造のサポートによって明らかにされます。

1.例：？キャッチーなスローガンはいいけれど、具体的に何を意味しているのかがわからない......。

2.テキストラッパーとしてOOPが良いというのは既に言われていることですが、それは手続き型プログラミングで完成されていないからです。

3.なぜ、このような「高度な構造物」を増殖させる必要があるのか？コードの性能を破壊することになるし、バグを発見するのが簡単で速くなるかどうかもわからない。

[Andrei01]

Alexey Volchanskiy:
最近のコンパイラは、平均的な、あるいは優秀なプログラマーよりも何倍も優れた最適化を行っています。

単純でつまらないことでも、人が座って手作業でアルゴリズムを書いたからできるのかもしれませんが、非標準のものであれば、特にOOPeshehの機能がそこに見出された場合、確実性からはほど遠いものになります。

[Andrei01]

Alexey Volchanskiy:
ドライバーでは、たしかにアッセブラーを使っていますが、それはスピードのためではなく、ハードウェアとの連動がしやすいから......。

なぜ、複雑で分かりにくく、スピードも遅いものを欲しがるのか？

[Sergey Dzyublik]

荒らす、立ち去る、気に入らない、使わない。

[Georgiy Merts]

Andrei:

例えば？キャッチーなスローガンはいいが、具体的に何を言っているのかわかりにくい・・・3．

2.テキストラッパーとしてOOPが良いというのは既に言われていることですが、それは手続き型プログラミングのスピードが上がっていないためです。

3）なぜ、このような「開発された構造物」を増殖させなければならないのか？コードのパフォーマンスには最悪でしょうし、その分バグをキャッチしやすく、早くなるということでもありません。

1.例えば、オブジェクトの配列が必要だとします。問題は、例えば、オブジェクトの追加や削除、ソートなどの動作を変更する必要がある場合です。OOPでは、ポインタ配列の適切なサポートとそれを使った作業は、ベースとなるオブジェクトに内包されています。実際に配列に含まれる子孫オブジェクトを変更しても、何も影響はありません。手続き型では、配列に含まれる実際のオブジェクトを変更する場合、少なくともオブジェクトのサイズの変更を考慮しなければならないため、通常はより多くの場所に影響を及ぼします。その分、エラーになりやすい。

クロスプラットフォーム - また、OOPスタイルで整理する方がはるかに便利です。例えば、取引ポジションをリクエストすると、インターフェースが表示され、どのプラットフォームで作業しているかは関係ありません。インターフェースは仮想機能を 提供し、その上ですべての注文（MT4用）またはポジション（MT5）のデータを取得でき、専門家の観点からは - 違いはありません。Expert Advisor は、どのプラットフォームで動作するかを知る必要はありません。

2.手続き型プログラミングの仕上げ」とは、「オブジェクト-プロシージャの記述」、つまり、データとプロシージャ（OOPのオブジェクトを表すもの）の間に何らかのリンクを作るということです。

3.そして、例えば、何種類ものオーダーがあり、それらは共通点が多い。COrderInfoというオブジェクトを作り、それを基本オブジェクトとし、その子孫でさまざまな種類のオーダーを表現するのが合理的だろう。この場合、トレードプロセッサー（私はCTradeProcessorクラスを持っています）は、渡されたその注文を、この注文を処理するために必要なそれらの手続きによって、自動的に正確にサポートすることになります。

クロスリンクが少ないところでは、バグをキャッチしやすいのです。これはまさにカプセル化とポリモーフィズムによって提供されるものです。トレードポジションインターフェース（CTradePositionI）を要求し、このポジションを表す実クラス（CMT4PositionInfo,CMT5PositionInfo）との接続は全てこのインターフェースを通してのみ行われ、まさにトレードポジションデータを返す実関数を直接操作するよりもエラー修正が容易になることに貢献する。