PLO - ページ 4

新しいコメント
 
mrProF:

私の勘違い-「OOPで書けてOOPでなければ書けないタスクはない」。


何となくそんな風に理解していました。
 
MQL4でリスト、ツリー、グラフの実装に挑戦してみよう。これはありえないことです。MQL5ではそれが簡単にできます。車輪を再発明する必要さえなく、С++でコードを見つけ、最小限の手直しで使うことができるのです。もちろん、例として挙げた型も、クラスとして設計した方が良い。ニューラルネットワークや ファジーロジックなど、様々なものがMQL5で実装できるようになりました。しかし、それぞれのツールは解決すべき課題に適したものであるべきで、OOPは必要な場合にのみ使用されるべきものであることは間違いありません。新機能を非難する人たちの叫びは滑稽です。嫌なら使わなければいい、誰も使うことを強制しているわけではありません。関数型プログラミングを使用する。
 
FoxRex:
MQL4でリスト、ツリー、グラフの実装に挑戦してみよう。これはありえないことです。MQL5では、車輪を再発明する必要さえなく、С++でいくつかのコードを見つけ、最小限の手直しでそれを使うだけで、簡単にできます。もちろん、例として挙げた型も、クラスとして設計した方が良い。ニューラルネットワークやファジーロジックなど、様々なものがMQL5で実装できるようになりました。しかし、それぞれのツールは解決すべき課題に適したものであるべきで、OOPは必要な場合にのみ使用されるべきものであることは間違いありません。新機能を非難する人たちの叫びは滑稽です。嫌なら使わなければいい、誰も使うことを強制しているわけではありません。関数型プログラミングを使用する。

不可能」と「困難」を混同しないでください。手続き型プログラミングで解決できない課題で、同時にOOPで解決できるものはありません。
そして、一般的には、アセンブリ言語で書くことができ、あなたはリラックスすることができ、既製服を提供する:)

OOPは、同じ手続き型プログラミングをベースに、データと関数の分離を追加したものです。
例えば「Hello world！」というプログラムをOOPで書くと時間がかかるが、大規模なプロジェクトでは 早く書ける。 OOPで書くか書かないかの線引きは非常に曖昧で、プログラマーの経験、目標、好みによって異なる。
個人的には、OOPの「ボトルネック」や「幅」を知っているし、OOPプログラミング（C++、JavaScript、PHP）の経験もあるので、ほとんどの場合、OOPで書いた方が都合がいいのです。
しかし、短いテストスクリプトを書くのであれば、OOPは使いません。

アドバイス：実際の問題でOOPに切り替える前に、例えば、2つの数字を足すクラスを書くなど、簡単な例で練習しておくとよいでしょう。
練習もせずに、OOPの本を読んで、OOPで本格的なプログラミングを始めることはまずありえません。
慣れてくれば、OOPの観点から考えるようになり、クラスとして設計しなければならないものと、そうでないものが見えてくるはずです。

 
リスト、ツリー、グラフ、MQL4ではポインターを持つことができません。
 
FoxRex:
リスト、ツリー、グラフ、MQL4ではポインターを持つことができません。

これは実装であり、結果ではないことに注意してください。
結果（プログラム）のためにプログラミングしているのか、プログラムの実装のためにプログラミングしているのか？
これらのメソッドを一切使わず、配列と値渡しで整理すればいいのです。
複雑で時間がかかるが、可能性はある。

 
mrProF:

これは実装であり、結果ではないことに注意してください。
結果（プログラム）のためにプログラミングしているのか、プログラムの実装のためにプログラミングしているのか？
これらのメソッドをすべて使わず、配列や値渡しでアレンジすることも可能です。
複雑で時間がかかるが、可能性はある。

Windowsと OOPの 時代に「生まれた」人は、DOSと C/Turbo Pascal（Asmは言うに及ばず）を理解できない......。

もちろんIMHOですが...。

 
Interesting:

Windowsと OOPの 時代に「生まれた」人は、DOSや C / Turbo Pascal（Asmは言うに及ばず）が何であるかを理解できない...。

もちろんIMHOですが...。

クラッカーがasmとは何かを理解するために :)
プログラマーは一度にいくつもの方法で問題を解決することができるので、変化のためにすべてを試してみる必要があります :)
でも、Asmでプログラムをデバッグするのは憂鬱です :)
 
mrProF:

これは実装であり、結果ではないことに注意してください。
結果（プログラム）のためにプログラミングしているのか、プログラムの実装のためにプログラミングしているのか？
これらのメソッドをすべて排除し、配列と値渡しで整理することも可能です。
複雑で時間がかかるが、可能性はある。

配列が動的であれば、実際にやってもいいというのは賛成です。しかし、これがあまりエレガントな解決策でないことは、あなたも認めるところでしょう。アセンブラでやった方が簡単なんです。そして、OPPはWindowsより前に誕生しています。そして、彼のアイデアによって、私はMS/CT用のアセンブリ言語でプログラミングをすることができました。 そして、私が初めて手にしたプログラミングの教科書は、クヌースの3巻本でした。
 
FoxRex:
そうですね、配列が動的であれば可能です。しかし、あまりエレガントな解決策でないことはご承知のはずです。アセンブラでやった方が簡単なんです。でも、OPPはWindowsより前に生まれているんですよ。そして、彼のアイデアによって、私はMS/CT用のアセンブリ言語でプログラミングをすることができました。そして、私の最初のプログラミングの教科書は、クヌースの3巻本でした。
私もそう思います。
そう考えると、「OOPは便利」なんですね。）

あと、「OOPを使うのが嫌なら使うな」ですね :)

2つのシンプルなコンセプト...

 
mrProF:

OOPは大規模なプログラムには向いている。
コードが50行以下であれば、OOPは必要ない。
しかし、コードが非常に大きくなると、何が何に属しているのか、コメントを通してしか理解できないことがほとんどです。
変数が意図したとおりに共有されないと、エラーが発生する確率が高くなり、混乱する。
OOPでは、変数はメソッド（関数）と共にコンテナ（クラス）の中に格納することができます。

OOPで書けて、OOPでなければ書けないタスクはないのです。
利便性の問題です))

OOPは問題を解決する方法ではなく、コードの構造化の方法である。

プログラムが "Hello word "よりも大きくなると、OOPを使用 する必要があります。

総じて、MQL4は数年前から知っていますが、その惨めさには驚きを禁じ得ません。第4のMQLは、クラシカルCの実力からすると星のように遠い存在です。MQL5では、開発者は前進を決意しました。機能が増え、プログラミングが容易になりました。確かに言葉は複雑になりましたが、この製品は小学生向けに作られたものではありません。

12345678
新しいコメント