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

 
Dmitiry Ananiev:

フリーランスの市場での受注状況を見てください。1日で対応できない注文はほとんどない。TORに合意し、顧客の質問に答え、逆上し、仕事を引き受ける/納品することに多くの時間が費やされる。もちろん、MQL5で同じテトリスが書けるのは嬉しいことです。しかし、この言語は別のことを想定して作られています。
既製のストラテジーに基づくExpert Advisor Wizardは、OOPを使用した例です。一度やってみたけど、理解できたよ。でも、今はその仕組みを覚えていないんです。
手続き的なスタイルで、すべてを明確に記述しています。私はいつOOPに完全に切り替えると思う?

別の例では、書きたい絵があるとします。シンプルな「ペイント」を使うのか、それとも何百ものプラグインを搭載した「フォトショップ」を使うのか?はい、Photoshopさえダウンロードしておけば、5回目からは全部Paintでやって、この作業は忘れますよ。



個人的には、スピードだけならMT5だけでいいと思っています。開発には、いつどこでプログラムが遅くなるのかがわかりやすいMT4を使っています。OOPであろうとなかろうと、MT5の方がずっとカッコイイ。
 
Реter Konow:
まあ、個人的にはスピードが速いので、少なくともMT5でしか作業しないつもりです。開発にはMT4を使っています。プログラムがいつ、何に対して遅れているのかがわかりやすいからです。OOPであろうとなかろうと、MT5の方がずっとカッコイイ。
みたいな音がする。私はクルザックを、妻はスマートを所有しています。クルザックは、アレです。だから、昼間はスマートで食料品を買い、夜はビールを飲みに行くんです。駐車しやすいし、ガソリンもあまり燃えないし、修理もあまり必要ないからです。
 
Реter Konow:

冗談でしょうけど、想像では、このアプローチには乗り切れないほどの見通しがあるんです。時間をかけて、システムの自己改善機構をスタートさせることができそうです。論理カーネルを作って、いろいろな仕組みをランダムに生成させたら。あとは、選んで選ぶだけ。そして、少しづつすり潰していく...。カーネルのおかげで、信じられないようなことができるんです。


Peterさん、すみません :) でも、クラスでやる方が簡単というか、快適なんです。

 
Dmitiry Ananiev:
みたいな音がする。私はクルザックを、妻はスマートを所有しています。クルザックは、アレです。だから、昼間は食料品を買いに、夜はビールを飲みに、スマートに乗っているんです。駐車しやすいし、ガソリンもあまり食わないし、修理もあまり必要ないからです。

ウィットに富んでいる。しかし、私にとって今の本当の利点は、MT4の遅さです。開発が終わるまではただ、スローの方がはっきり見えるんですけどね...。冗談じゃない。

それなら、クソの役にも立たないので必要ないでしょう)

 
Dmitiry Ananiev:

フリーランスの受注に目を向ける。1日で注文が実現することはまずない。取引条件の合意、顧客の質問への回答、顧客の鼻を明かすこと、そして仕事の受諾/納品に多くの時間が費やされるのです。

...
手続き的なスタイルで、すべてを明確にする。いつOOPに完全に切り替えると思う?

別の例では、写真にキャプションを付ける必要があります。シンプルなPaintやPhotoshopに100のプラグインを使う?Photoshopをダウンロードする頃には、5回目にしてすべてPaintでやってしまい、この作業のことは忘れてしまいます。

もし、使い捨てのコードを書いていないなら、OOPを使う ことは本当に正当化されるでしょう。例えば、私がOOPを使うのは、すでにリリースされた製品のバグを捕まえるのにコストがかかりすぎるからです。
 
Nikolai Semko:

Peterさん、すみません :) でも、クラスでやる方が簡単というか、快適なんです。

言ったでしょ、「人それぞれ」)。私はクリエイティブなので、そういうアイデアを思いつくのです)。何がいけないんですか?

 

多くのブローカーがMQL4プラットフォームを人気だと言いながら、MQL5にはこの言葉を適用しないのは、どう説明すればいいのでしょうか。

明らかに、その違いは、マスターするのがより困難なOOPにあり、結果として、書かれたコードのデバッグとサポートにあります。

プロのプログラマーにとって、この要件は重要ではありません。それどころか、プログラマーは通常時給制であり、複雑なコードは単純に時給が高くなるため、「複雑であればあるほど良い」というのは、多くの理由から実際にメリットがあるのです。また、他のプログラマーがコードを解読・理解することが難しくなり、雇用主のそのプログラマーへの依存度が高まるなど。

また、通常、時間単位ではなく、プロジェクト 単位で給与や自分の時間が支払われる取引目的の場合、このルールが機能しないことは明らかです。

 
Vasiliy Sokolov:
もし、一回限りのコードを書いていないのであれば、OOPは 本当に正当化されるでしょう。例えば、私がOOPを使うのは、すでにリリースされた製品のバグを捕まえるのにコストがかかりすぎるからです。

全く同感です。これがOOPの最大のメリットです。

 
Andrei:

..

明らかに、すべての違いは、マスターするのがはるかに困難であるOOPにあり、結果として、書かれたコードのデバッグとサポートにあります。

プロのプログラマーにとって、この要件は重要ではなく、逆に「複雑であればあるほど良い」というのが多くの理由です。なぜなら、通常プログラマーは時間給で支払われ、複雑なコードでは時間給でより多く稼ぐことができます。また、他のプログラマーがコードを解読・理解することが難しくなり、使用者のこのプログラマーへの依存度が高まる、などです。

...

本当に勘違いしていますね。使用者は、あなたが描いているような馬鹿ではありません。特に絡まったコードにこれ以上お金を払う人はいないでしょう。誰しもが、プロジェクトを 迅速に実行し、最小限の工数で、しかも書き換えや修正の必要がないシステムを手に入れたいと思うものです。だから、まさにOOPを知ることを要求されるのです。
 
Andrei:

多くのブローカーがMQL4プラットフォームを人気だと言いながら、MQL5にはこの言葉を適用しないのは、どう説明すればいいのでしょうか。

明らかに、この違いはOOPにあります。OOPをマスターするのはより難しく、結果として、書かれたコードのデバッグとメンテナンスが難しくなります。


しかし、MQL5では手続き型のプログラミングも可能です。これはC#ではありません。人気がないのはどうなんでしょう。時は流れ、世界は変化しています。でも、このプラットフォームには、MT4にはない多くの利点があります。これらの利点は何の意味もないのでは?