手続き型コードにできなくて、OOPコードにできることは何ですか？
OOPは自然界と同じように機能し、考えるように設計されています。例えば、戦争ゲームを開発する場合、多くの種類の車両、多くのスキルを持った兵士、多くのスペックを持った武器があることを想像してみましょう。
このようなゲームをOOPなしで開発することは、開発者にとって、これらの種類のオブジェクトをすべて追跡し、データ構造とメモリをうまく管理することは苦痛であり、また、継承のようなOOP機能をシミュレートすることは難しいでしょう（それは可能ですが）、OOPは、思考と開発を容易にし、コードを書いて読み、デバッグすることを容易にしました。
必要以上にOOPを使うと、コードの理解や読み方が不親切になることがあります（私の個人的な見解ですが）これは好ましくないですね。
実際、手続き型コードからOOPへのリファクタリング、あるいはその逆ができないタスクは存在しないと思います。違いは、コードの保守性と可読性です。例えば、手続き型コードでは、グローバルデータやローカルデータ（変数）を参照することができます。これに加えて、OOPでは、オブジェクトの内部変数（ステート）というスコープが追加されます。同じロジックを手続き型に実装する場合、追加のコードやデータ構造で 何らかの回避策が必要になりますが、OOPではこれらを非常に簡単かつ自然に利用することができます。つまり、OOPはより短く、より良いコーディングの方法なのです。
OOPの最も重要な部分である継承ツリーを含むオーバーロードされた仮想関数に対する回避策をどのように構築したいのですか？構造体について話しているようですが、OOPではありません。
OOPは自然界と同じように機能し、考えるように設計されています。例えば、戦争ゲームを開発する場合、多くの種類の車両、多くのスキルを持つ兵士、多くのスペックを持つ武器があることを想像してみましょう。
OOPなしでこの種のゲームを開発することは、開発者にとって、これらの種類のオブジェクトをすべて追跡し、データ構造とメモリをうまく管理することは苦痛であり、また継承のようなOOP機能をシミュレートすることは難しいでしょう（それは可能ですが）、OOPはコードの読み取りとデバッグを書くためにそれを考え、開発も容易にしました。
必要以上にOOPを使うと、コードの理解や読み方が不親切になることがあります（私の個人的な見解ですが）これは好ましくないですね。
手続き型コードにできないことで、OOPコードにできることは？
アラン・ヴェリエン 2016.05.22 14:03
手続き型プログラミングに対するオブジェクト指向プログラミングの優位性について、有益な情報を集めたいと思い、このトピックを開設します。
また、mql4とmql5は同じOOP言語を提供しているので、このトピックは言語に依存しません（現時点ではmql4でまだ利用できない新しい高度な 機能を除く）。
私は、OOPの支持者と反対者の間の「戦争」を望まないので、このトピックは密接に管理されます。
また、高度な理論や抽象的な概念ではなく、あなたの主張を説明するための例やコードを提示してください。
EDIT: このトピックは言語に依存しませんが、トレーディングとmql4/mql5について話しているので、「戦争ゲーム」や「リンゴとオレンジ」のような例は避けてください。
私はOOPの大ファンです。手続き型のMQLに戻るとは想像すらできません。プログラムをより複雑にするのは簡単です。とにかく...MQLの問題点は、新しいユーザーがここから始めるのが難しいということです。
- 組み込みのイベント・メソッドはOOではありません。イベントメソッドにフックする必要があり、そのためにはルートレベルでリスニングオブジェクトを宣言する必要があります。この設計では、基本的なOOPの原則の1つが損なわれています。
- 共通のパターンを持つ「システム」コードパッケージがない。このため、ユーザー間で互換性のあるパッケージを作ることができず、真面目なOOPコーダーは自分のプライベートなパッケージを作るのに多くの時間を必要とします。サポートされていないクラス名のプレフィックス（パッケージ名）は、外部コードを再利用できない場合には、小さな問題に過ぎません。
ですから、MQLでOOPを学び始めるのはお勧めしません。コーダーは自分が何を必要としているかを知る必要があります。
"if...then...else..." という文があれば大丈夫です。
ああ、そうですか;)そうでもない;)もしネイティブなものが変な仕事をするのであれば、ポインターを使うことになりますが、MQLには制約があります。しかし、MQLには制限があります。そして、あなたがこのスレッドの質問に対する答えとして不条理なコードを受け入れるならば、それはまったく時代遅れです;)不条理が良いフロンティアであることに同意しますか？さあ、一度だけ、私のエゴのために、イエスと言ってください;)
コードはゴールに到達しているかどうか、仕様通りに動いているかどうかで、何も不合理なことはないのです。
問題は、「手続き型にできなくて、OOPにできることは何か」ということです。Stanislavは、OOPは手続き型と同じことができるが、「より短く、よりきれいに」できる、と言って います。私はこの意見に賛成です（ただし、より短いという点については、それほど重要 ではありません）。
私はプログラマーとして、GUIのプログラミングをすることが多かったです。GUIを完全にコーディングすることは不可能で、複数の方向からif then elseで通信する必要があります。多くの記述が必要で、コードが読めなくなるし、結局は遅すぎるということになる。なぜなら、クリックするたびに結果が出るまでコーヒー一杯飲まされてはたまらないからです。
CPUはOOPを知らないので、もちろんポインタや複雑な配列を使って、すべてを記述することは可能です。でも、そんなことは不可能です。また、私のスクリーン・コンテンツをフィルムにリアルタイムで描き、それを壁に投影するプロジェクターを 1万人雇うこともできます。これもゴールなのでしょうか？
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
このトピックは、オブジェクト指向プログラミングと手続き型プログラミングの長所について、有益な情報を集めたいと思い、開設しました。
また、このトピックは、mql4とmql5が同じOOP言語（現時点ではmql4で利用できないいくつかの新しい高度な 機能を除く）を提供しているため、言語に依存しません。
私はOOPの支持者と反対者の間の「戦争」を望まないので、このトピックは厳密にモデレートされます、あなたの時間と私の時間を無駄にしないでください。
また、高度な理論や抽象的な概念ではなく、あなたの主張を説明するための例やコードを提示してください。
EDIT: このトピックは言語に依存しませんが、トレーディングとmql4/mql5について話しているので、「戦争ゲーム」や「リンゴとオレンジ」のような例は避けてください。