Наконец-то мы добрались до самой важной темы во вступительном курсе. Сегодня мы будем говорить о классах и объектах. Выпуск небольшой и не сложный. Что есть хорошо. Класс - не что иное, как структура, к которой добавили функции. А объект - это структурная переменная. Данный материал будет более понятным, если вы хорошо освоились со структурами...
ジョージ・マーツ：
えー...よく意味がわからなかった。
TCと端末の分離を目指したのです。コードは、両プラットフォームで変更なくコンパイルできる必要があります。スーパータスク - トレードサーバと連動するクラスのみを記述することで、記述されたすべてのTSをWealhtLab Developerに転送することです。
//--------------------------------------------------
現在の課題に対して、その解決策をいくつかの基準で比較し、それぞれの有効性について結論を出すために質問しました。実用的な部分から話をそらしていますね。OOPの 有効性を主張する場合、それを実践で証明できなければなりません。でも、自分の意見を証明するために、トライする覚悟はできているんです。
では、現在の問題点は何でしょうか？覚えていてほしい)
関数へのポインタを使えば、OOPなしでも大丈夫です。しかし、ポインターを使わないのであれば、OOPに追いつけないことを理解しなければなりません。
あなたはプログラマーではないのですね？そして、自分がどこにいたのか、誰と、何について話していたのかを思い出してください ))
関数へのポインタを使えば、OOPなしでも大丈夫です。しかし、ポインターを使わないのであれば、OOPに追いつけないことを理解しなければなりません。
いや、OOPに追いつけないことを示す具体的なタスクがない限り、OOPを把握することはできない。残念ながら。これはあくまで言葉です。
現在、私は4年間のプログラミングの実務経験があります。毎日何時間もプログラミングしているので、安心して2倍してください。この間、数え切れないほどのさまざまな課題を解決してきました。OOPは まだ使ったことがないんです。なぜ必要なのか、理解できない。私の実務では、すべてのタスクがこれなしで解決することもあれば、それ以上に効率的に解決することもあります。
いや、OOPに追いつけないことを示す具体的なタスクがない限り、まったく把握できないのです。残念ながら。これはあくまで言葉です。
外部パラメータによってアルゴリズムを変える仮想のプログラムを想像してみると、膨大な数のバリエーションが存在する可能性があります。OOPを使わなくても解決できるのですが、あの多段式スイッチがいかにも間抜けに見えてしまうのです。しかも、バリエーションが増えるとパフォーマンスが落ちるのは明らかです。また、OOPでは初期化時にビルドが発生し、さらに動作時には無駄な分岐が発生しない、つまりバリアントを増やしても性能が落ちないことがわかります。
構造化プログラミングの特徴は、プログラムをコードのブロックに分割することである。
特定のタスクを実行するもの。この場合、構成要素は関数
とモジュール（別のファイルに移動することもあります。）
より現代的なのは、オブジェクト指向プログラミング（OOP）である。
OOPのコンセプトは、どちらかというとデータ編成を指しています。OOPはプログラマーの生活を楽にする。
OOPのキーコンセプトは、オブジェクトとクラスです。
クラスとは、機能を追加するための構造体である。そして、オブジェクトは構造化された変数やクラスのインスタンスです
構造化プログラミングはその第一歩です。それをマスターすることで、プログラマーはアドバンテージを得ることができるのです。OOPは次のような利点があります。
ある問題を解いて比べてみよう。
ここでは簡単な作業を紹介します（詳しく説明するとかなりの文章量になります）。
全てはOnTick()の中で行われます。例えば、ある条件を確認し、注文を出すとします。条件は重要ではなく、ある最大値か最小値であると仮定しよう。
ロボットは自然にチャートの上に立ち、このシンボルの気配値を取得する。OnTickという関数だけでなく、OnTrade、OnTimer、カスタム関数など、他の関数があることは明らかです。
したがって、共有されるすべての変数は、コードの冒頭でこれらの関数の外で宣言されなければなりません。例えば、シンボル名、アスク、ビッド、スプレッド、気配値の桁数などです。何十本もあるでしょう。
このロボットは1つのシンボル、つまり立っている場所だけで取引します。このようなチャートが20枚あると仮定して、そのすべてに同じロボットをインストールして、20ペアすべてについて同時に取引することにします。
しかし、これはMarketの一部のトレーダーが指摘しているように、多通貨取引ロボットでは ありません。
ここでは、これを多通貨対応ロボットにする必要があります。つまり、どのチャートにも（1つのチャートにのみ）貼り付けて、20組の取引を開くことができます。このように、テスターでシングルモードで起動すると、Market Watchに登録されているペアで取引されるようになります。
ここでは、OOPを使わずにどのように実装するかを説明します。すべての共通変数を20要素の配列に変換するのでしょうか？
また、すべてのペアで同時に呼び出される関数についてはどうでしょうか。
OOPなしではやっていけない。:)
追伸：私はロシア語教育を受けていないので、長文を書いてしまい、何ページも読む時間がありませんでしたので、ご注意ください。
関数へのポインタを使えば、OOPなしでも大丈夫です。ポインターを使わないと、OOPに追いつけないことを自分で自覚する必要があります。
私はそうは思いません。一時期、デジタルテレビのプログラムを書いていたことがあるのですが、コンパイラはC++でしたが、メモリが少ないのでCの中で使っていました。関数へのポインタは非常に多用されましたが、これはもうOOPとは言えないでしょう。
...
ここでは、OOPを使わない方法を紹介します。
...
ここで重要なのは、「どのように」ではなく、「なぜ」なのかということです。ターミナルにすでに実装されているものをなぜコーディングする必要があるのでしょうか。必要な数のチャートを開き、EAに添付するだけでいいのです。さらに、シンボルや時間枠が異なれば、パラメータも異なる可能性があります。
私はそうは思いません。以前、デジタルテレビのプログラムを書いていたとき、コンパイラはC++でしたが、メモリが少ないのでCで使っていました。関数へのポインタは非常に多用されましたが、OOPには程遠い状態です。
あまり便利ではありませんが、パフォーマンスに関してはポインタだけでも大丈夫です。
そして、利便性というのは相対的な概念です。
外部パラメータによってアルゴリズムを変える仮想のプログラムを想像してみると、膨大な数のバリエーションが存在する可能性があります。OOPを使わなくても解決できるのですが、あの多段式スイッチがいかにも間抜けに見えてしまうのです。しかも、バリエーションが増えるとパフォーマンスが落ちることは明らかです。また、OOPでは、初期化時にビルドを行い、作業中に不要な分岐を行わないため、バリアントを増やしても性能が落ちないことも明らかです。