OOPと手続き型プログラミングの比較
ここで大合唱するつもりはありませんが、OOPの支持者は、OOPなしの解決策よりもこの解決策がより効率的であることを明確に示す、問題を解決するコードを提出できないでしょうか？
私はOOPなしで問題を解決する達人ですが、OOPで問題を解決する達人と一緒に戦いたいと思います。
ここで大合唱するつもりはありませんが、OOPの支持者は、OOPなしの解決策よりもこの解決策がより効率的であることを明確に示す、問題を解決するコードを提出してもらえないでしょうか？
私はOOPなしの問題解決者であり、OOPありの問題解決 者と戦いたいと思っています。
これは、比較を再現できるプラットフォームではなく、プログラムは1ページ(1ファイル)です。ここでは、好きなように書いても、プログラムの性能やアクセスはほぼ同じレベルに保たれます。手続き型、OOP型など、どんなスタイルでも失敗する可能性はありますが。
このプログラムは1ページ(シングルファイル)であり、比較対象を再現できるプラットフォームではありません。ここでは、好きなように書くことができ、パフォーマンスやプログラムへのアクセスもほぼ同じレベルに保たれます。手続き型でもOOP型でも、どんなプログラミングスタイルでも失敗する可能性はありますが。
よくわからないんですけど。1ページのプログラム」とはどういう意味ですか？1つの課題を解決するために、2つの異なるアプローチを単純に比較することができます。比較する際には、ソリューションそのもの、コードのコンパクトさ、コードの読みやす さといった主要な基準で、それぞれのソリューションを評価する必要があります。
これらは、プログラミングにおける主な判断基準です。
- www.metatrader5.com
数百行に及ぶ巨大なコードブロックを書くこと。ほぼノーコメント。OOPなし。ロシア語のコード。すべてが非常に効率的に機能しています。100個くらいのファイルがつながっているのですが、プログラム内の方向性に悩むことはありません。おそらく、慣れてしまって、ずっと前に全部覚えてしまったからだと思います。メインはプログラムを知り、理解することであり、それ以外は二の次である。イミフ。
仕事の「効率」について議論することは可能です。
同じことが修正可能性にも当てはまります。もし、あなたのコードが異なる精度の見積書に使用される場合、修正が必要でしょうか、そして、その修正は簡単でしょうか？
このようなプロジェクトで 一番問題になるのは、とにかく変更を加えることです。練習でわかるように、ブロックが大きくなればなるほど、修正時にエラーが発生しやすくなる。コメントがないのは、プラスではなくデメリットです。そのため、たくさんのことを暗記しなければならないのです。
ここで大合唱するつもりはありませんが、OOPの支持者は、OOPなしの解決策よりもこの解決策がより効率的であることを明確に示す、問題を解決するコードを提出してもらえないでしょうか？
私はOOPなしで問題を解決する達人であり、OOPで問題を解決する達人と戦いたいと思っています。
このようなコードは、すでに上記で紹介しました。取引履歴を扱う完全な仮想インターフェイスがあります。私の仕事でも現職を はじめ、同じようなところで同じような仕組みが使われています。
OOPのおかげでMT4とMT5の完全な統一性があり、MT5ではヘッジかネッティングかに関係なく機能する。
また、まさにOOPのおかげで、1つのEAで、魔法の異なる複数のTSを簡単に使うことができます。
実際、OOPはコードのサポートを簡素化するために発明されたものです。同時に、執筆時に大きなコストがかかる。コードを書いて、そのまま使って、削除するのであれば、わざわざOOPにこだわる意味はないでしょう。OOPは、まさに同じコードが多くの場所で必要とされ、定期的に修正する必要がある場合に有利となります。
これに対応して、OOPの適用範囲と非適用範囲は、コードの保守や変更の必要性によって決定される。
効率」について議論することができます。
同じことが修正可能性にも当てはまります。あなたのコードが異なる精度の引用に使用される場合、変更が必要でしょうか、そしてその変更は容易でしょうか？
このようなプロジェクトで一番問題になるのは、とにかく変更を加えることです。練習でわかるように、ブロックが大きくなればなるほど、修正時にエラーが発生しやすくなる。コメントがないのは、プラスではなくデメリットです。そのため、いろいろなことを覚えなければならない。
また、ブロックの汎用性も評価基準のひとつです。もちろん、ブロックには、さまざまな作業に使えること、状況の変化に対応しやすいことが求められます。これはまさに私が持っているものです。例えば、私はいわゆる「フォーカス」の技術を使っています。つまり、主要なパラメータの値は常にグローバル変数 に固定され、その変数とすべてのブロックに入れられるのである。
ブロックの汎用性も評価基準の一つです。確かに、ブロックはさまざまな作業に使え、状況の変化にも対応しやすいものであるべきです。これはまさに私が持っているものです。例えば、私はいわゆる「フォーカス」の技術を使っています。つまり、主要なパラメータの値は常にグローバル変数 に固定され、その変数とすべてのブロックに入れられるのである。
グローバル変数もデメリットがありますね。すべてのブロックで利用可能なグローバル変数は、できるだけ少なくする必要があります。各ブロックが必要なデータだけを受け取り、可能な限り定型のデータだけを受け取り、変わるはずのないものを変えることがないようにするためです。
私のプロジェクトでは、Init()、OnTick()、その他のイベントの機能をカプセル化したCExpertクラスオブジェクトと、トレースマクロはプログラムのどの場所からでも機能しなければならないので、トレースを出力するログファイルであるCLogFileオブジェクトの2つだけがグローバル変数になっています。
なぜなら、シャーロック・ホームズが言ったように、ある瞬間、必要な知識は不要なゴミの山に埋もれてしまうからです。そして、メモリも故障することがあります。
グローバル変数もデメリットがありますね。すべてのブロックで利用可能なグローバル変数は、できるだけ少なくする必要があります。各ブロックが必要なデータだけを受け取り、可能な限り定型のデータだけを受け取り、変わるはずのないものを変えることがないようにするためです。
私のプロジェクトでは、Init()、OnTick()などのイベントの機能をカプセル化したCExpertクラスのオブジェクトと、トレースマクロがプログラムのどの場所からでも動作する必要があるため、トレースを出力するログファイルであるCLogFileオブジェクトの二つだけがグローバル変数になっているのです。
記憶に頼ることは、少なくともシャーロック・ホームズが言ったように、必要な知識がいつの間にか不要なゴミの山に埋もれてしまうからだ。そして、メモリも故障することがあります。
実際に比較する必要があります。そうでなければ、これは無駄な議論です。
なぜ「役に立たない」のか？とても便利です。
しかし、実際に「サポートのしやすさ」を比較するとどうでしょうか。
例えば、1つの巨大なブロックとして書かれたコードと、機能的な部分に分割されたコードとでは、どちらの場合も変更の導入は全く同じです。 唯一の違いは、最初のケースでは、変更によって影響を受けるすべてのリンクを記憶し、それを考慮しなければならないことです。2番目のケースでは、ユニットは動作に必要なリンクにしかアクセスできないため、変更は利用可能なすべてのリンクに影響します。何も覚える必要はありません。一貫して、変更したいブロックに利用可能なすべてのものを調整します。
それが、この違いをどう評価するかということです。作業量は全く同じです !
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索