class CStrategy : public CObject { protected: ulong m_magic; // 魔术 string m_symbol; // 符号(交易工具) ENUM_TIMEFRAMES m_timeframe; // 图表周期(时间框架) double m_fixedLot; // 未结头寸的大小(固定) public: // 构造函数 CStrategy(ulong p_magic, string p_symbol, ENUM_TIMEFRAMES p_timeframe, double p_fixedLot); virtual int Init() = 0; // 策略初始化 - OnInit 事件处理 virtual void Tick() = 0; // 主要方法 - OnTick 事件处理 };
如果有构造函数,为什么还需要 Init 方法?
出于某种原因,他们立即将 TS 类限制为一个符号和一个时间框架。
这似乎更符合逻辑。
class SYSTEM { public: virtual void OnTick() {} };
会是的。由于某种原因,它被用于子类中。如果不使用 Deinit(有一个析构函数),那么不使用 Init(有一个构造函数)也是合乎逻辑的。
//+------------------------------------------------------------------+ //| 构造函数| //+------------------------------------------------------------------+ CSimpleVolumeStrategy::CSimpleVolumeStrategy( ulong p_magic, string p_symbol, ENUM_TIMEFRAMES p_timeframe, double p_fixedLot, int p_signalPeriod, double p_signalDeviation, double p_signaAddlDeviation, int p_openDistance, double p_stopLevel, double p_takeLevel, int p_ordersExpiration, int p_maxCountOfOrders) : // 初始化列表 CStrategy(p_magic, p_symbol, p_timeframe, p_fixedLot), // 调用基类构造函数 signalPeriod_(p_signalPeriod), signalDeviation_(p_signalDeviation), signaAddlDeviation_(p_signaAddlDeviation), openDistance_(p_openDistance), stopLevel_(p_stopLevel), takeLevel_(p_takeLevel), ordersExpiration_(p_ordersExpiration), maxCountOfOrders_(p_maxCountOfOrders) {} //+------------------------------------------------------------------+ //| 专家的初始化函数 //+------------------------------------------------------------------+ int CSimpleVolumeStrategy::Init() { // 加载指标以获取刻度线量 iVolumesHandle = iVolumes(m_symbol, m_timeframe, VOLUME_TICK); // 设置刻度卷数组接收器的大小和所需的寻址方式 ArrayResize(volumes, signalPeriod_); ArraySetAsSeries(volumes, true); // 设置通过交易下单的神奇号码 trade.SetExpertMagicNumber(m_magic); return(INIT_SUCCEEDED); }
而人为地缩小可能的 TC 范围是一个奇怪的解决方案。
你还可以清楚地看到,由于 OOP 的存在,输入变得繁琐。把它去掉会很好。
之所以暂时不使用 Init(),是因为构造函数不可能返回结果。但我们有可能永远都不需要在策略初始化时返回 INIT_SUCCESS 以外的结果。因此,这个方法很有可能在将来被移除。
以符号和时间框架的形式分配强制策略属性是一种有意的限制。在设计上,多个符号的交易将通过该类继承者的多个实例来完成,但每个特定实例只与单个符号一起工作。我还没有发现任何策略会受到这种限制的阻碍。相反,在考虑的每种策略中都发现了这些参数,这就是为什么决定将它们一次性放入基类的原因。
不过,我打算在将来考虑一些多符号策略,因为这些策略无法分成几个独立的单符号策略(如果有的话)。我不认为基类中的符号和时间框架属性 会对使用多个符号和多个时间框架的子类的实现造成很大阻碍。
这似乎是编译器的一个错误,当这样调用时,它不会对这个方法签名发誓。
expert.AddStrategy(new CSimpleVolumeStrategy( magic_ + 1, "EURGBP", PERIOD_H1, NormalizeDouble(0.34 * depoPart_, 2), 130, 0.9, 1.4, 231, 3750, 50, 600, 3)
应该是这样的
CAdvisor::AddStrategy(CStrategy* strategy)
新文章 开发多币种 EA 交易(第 1 部分):多种交易策略的协作已发布:
交易策略是多种多样的,因此,或许可以采用几种策略并行运作,以分散风险,提高交易结果的稳定性。但是,如果每个策略都作为单独的 EA 交易来实现,那么在一个交易账户上管理它们的工作就会变得更加困难。为了解决这个问题,在一个 EA 中实现不同交易策略的操作是合理的。
我们需要决定我们想要什么,以及我们拥有什么。
我们有(或几乎有):
我们想要:
我们将使用面向对象的方法、MQL5 和 MetaTrader 5 中的标准测试器。
手头的任务相当繁重,因此我们将逐步解决。
作者:Yuriy Bykov