enum Direction
{
BUY,
SELL,
NO_SIGNAL
};
class Signal
{
public:
Signal() {}
~Signal() {}
virtual Direction check_signal() { return NO_SIGNAL; }
};
次に、自分か3人に、例えば3種類の指標についてシグナルを書かせる。
class RSISignal : public Signal
{
public:
RSISignal() {}
~RSISignal() {}
Direction check_signal()
{
Direction result;
// Checking signal with RSIreturn result;
}
};
信号が使われている場所だけで十分です。
Signal* signal;
switch signal_type
{
case RSI : signal = new RSI;
case CCI : signal = new CCI;
case MA : signal = new MA;
};
if (signal.check_signal())
.....
素晴らしいOOPで利益はどうなんだ。覚えてもすぐに消えてしまうのでしょうか？
OOPは、コンパクトで明快、かつエレガントなコードを書く能力を与えてくれます。コードの記述、修正、デバッグに費やす時間は数分の一になり、非常に高価なものになります。より高度な取引システムを構築し、より多くの取引オプションを試すことができます。もちろん、収益性の高いボットのアイデアがない場合は、何もしない方がよいでしょう。さらに、バグが発生した場合に直接的に損失を被る確率を忘れてはいけませんが、優れたOOPコードではその確率ははるかに低くなります。
OOPは、コンパクトで明快、かつエレガントなコードを書く能力を与えてくれます。
そんなことはない。
ということはありません。
まあ、意図的に複雑化するようにタスクを設定すれば、たしかにOOPの方が意図的に複雑化する機会は多いですね。
しかし、メガネをかけた猿のようにならなければ、OOPによって、より明確で構造化された、メンテナンスしやすいコードを得ることができます。
私はOOPに反対しているわけではないんだ、友よ。そのオブジェクトのアイデアが好きです。そして、部分的にですが、構造体というか、構造体の配列の形で使っています。トレーディングでは、チャートからすべてのデータを保存し、すべてのバーでループを実行しないようにすれば十分です。でも、これだけでいいと思うんです。もちろん、慣れている人は、すべてをOOPで書くこともできます。しかし、手続き的なものと同様、採算が合うとは言い難い。問題全体は収益性の高いシステムで、それがあれば、goto-codeで書くことができる :)
枝葉の話題は、それを解決するための方法にも及んでいる。
そして、構造体というか、構造体の配列という形ではありますが、部分的に使っています。
Javaでは、POJO（Plain Old Java Object）という名前もあります。
;)
OOPコードは、より明確で構造化されており、メンテナンスが容易です。
これは必ずしもそうではなく、OOPではなく、コードのクリーンさ、ネーミングに依存します。
私はOOPに反対しているわけではないんだ、友よ。そのオブジェクトのアイデアが好きです。そして、部分的にですが、構造体というか、構造体の配列の形で使っています。トレーディングでは、チャートからすべてのデータを保存し、すべてのバーでループを実行しないようにすれば十分です。でも、これだけでいいと思うんです。もちろん、慣れている人は、すべてをOOPで書くこともできます。しかし、手続き的なものと同様、採算が合うとは言い難い。問題全体は収益性の高いシステムで、それがあれば、goto-codeで書くことができます :)
枝葉の話題は、それを解決するための方法にも及んでいる。
構造体を使うのはOOPではありません。OOPのメリットは、OOPパターンを使い始めたときからすべて始まります。継承、シングルトン、オブジェクトファセット、インターフェースクラスなど。また、2人以上のチームであれば、OOPはなくてはならないものです。例えば、こんな感じです。
次に、自分か3人に、例えば3種類の指標についてシグナルを書かせる。
信号が使われている場所だけで十分です。
セニョールであるあなたは、関数本体の実装から完全に抽象化されています。実装やどの指標を使うかは、あなたにとって重要ではありません。check_signalを使うだけでいいんです。この例では、1つの機能を使用しています。また、クラス内に多くの関数がある場合、コンフィグや他の選択肢に依存する実装では、スイッチを挿入する必要があります。また、データベースや、例えばログファイルをたくさんの場所で使う場合 - グローバル変数を作って、すべての段階でその状態を制御しなければなりません（ファイルやデータベースが開かれているかどうかなど）。この目的のためにシングルトンを使用する場合、ログファイルやベースオブジェクトを使用する場所には常にオブジェクトのコピーが存在し、ベースやファイルを再オープンしたり、ステートフラグを使用したり、バッファードログを作成して出力のたびにディスクに書き込まないようにしたり、といったことができることを確認できます。1万行を超えるコードがあると、開発者にとって機能が生き地獄になる。そして、半年後にはコードの半分を忘れてしまい、手直しするのは生き地獄と化すでしょう。その上、優れたOOP設計により、どこかを変えたらすべてが地獄に落ちるという心配をせずに、新しい機能を追加したり、古い機能を編集したりすることができるのです。
5と4のOOPは何が違うのですか？啓蒙活動。純正の環境設定の差は歴然としています。そうですね......バーが端から番号になっていますね。その他に明らかな言葉の違いは見当たりません。
最低限、テレスコープ関数の束はようやく取り除かれたし、何よりも膨大な数の便利なクラスを持つ標準ライブラリが追加されたのだ。
最低限、テレスコープ関数の束をようやく取り除くことができたし、何よりも膨大な数の便利なクラスを持つ標準ライブラリが追加されたのです。
特にObject.mqh
を引用していますね。）
話題は OOPコースをマスターして擁護できるようになったかどうかではない...私見ではクソマスタリング
とにかく、教科書を持って、明日から学校へ行こう。