class CTradeProcessorI : public CMyObject
{
public :
void CTradeProcessorI() { SetMyObjectType(MOT_TRADE_PROCESSOR_I); };
virtualvoid ~CTradeProcessorI() {};
// Настроечный интерфейсvirtualvoid SetSlippage( uint uiSlippage) = 0 ;
// Торговый интерфейс// Все функции возвращают код возврата торгового сервераvirtualint Buy( long & lTicket,ECurrencySymbol csSymbol, double dVolume, double dTP= 0 , double dSL= 0 , ulong ulMagic = 0 , string strComment = NULL ) = 0 ; // Всегда по цене Ask, если успешно - возвращается lTicketvirtualint Sell( long & lTicket,ECurrencySymbol csSymbol, double dVolume, double dTP= 0 , double dSL= 0 , ulong ulMagic = 0 , string strComment = NULL ) = 0 ; // Всегда по цене Bid, если успешно - возвращается lTicket virtualint ModifyTPSL(CTradePosComponentI* ptpcComponent, double dTP= 0 , double dSL= 0 ) = 0 ;
virtualint ModifyTPSL( long lTPCTicket, double dTP= 0 , double dSL= 0 ) = 0 ;
virtualint CloseTradeComponent(CTradePosComponentI* ptpcComponent, double dCloseVolume= EMPTY_VALUE ) = 0 ; // dCloseVolume - закрываемый объем. Если равен EMPTY_VALUE или равен или больше, чем объем торговой компоненты с указанным тикетом - закрывается вся торговая компонента. virtualint CloseTradeComponent( long lTPCTicket, double dCloseVolume= EMPTY_VALUE ) = 0 ; // dCloseVolume - закрываемый объем. Если равен EMPTY_VALUE или равен или больше, чем объем торговой компоненты с указанным тикетом - закрывается вся торговая компонента. virtualint PendingSet( long & lTicket,ECurrencySymbol csSymbol, ENUM_ORDER_TYPE otOrderType, double dSetPrice, double dVolume, double dTP= 0 , double dSL= 0 , ulong ulMagic = 0 , string strComment = NULL ) = 0 ; // если успешно - возвращается lTicketvirtualint PendingDelete( long lTicket) = 0 ;
virtualint PendingDelete(COrderInfoCore* poiOrder) = 0 ;
virtualint PendingModify( long lTicket, double dSetPrice, double dTP= 0 , double dSL= 0 ) = 0 ;
virtualint PendingModify(COrderInfoCore* poiOrder, double dSetPrice, double dTP= 0 , double dSL= 0 ) = 0 ;
// Проверка кода возвратаvirtualbool TradeOperationWasSuccessful( int iTradeResCode) = 0 ;
// Если функция возвращает true, то при возникновении пользовательских ошибок (iTradeResCode > ERR_USER_ERROR_FIRST) советник прекратит работу// В случае false - работа будет продолженаvirtualbool IsUserErrorsFalal() = 0 ;
};
이것은 거래 프로세서 인터페이스입니다. MT4와 MT5 모두에서 동일합니다.
사용자는 이 인터페이스를 수신하기만 하면 됩니다. 그는 거래 활동에 대한 모든 가능성을 가지고 있습니다. 그는 MT4 또는 MT5에서 자신이 어디에 있는지 알 필요조차 없습니다. 구매를 해야 합니다. 구매 기능을 호출하세요. 이것은 당신을 위해 열린 거래 구성 요소의 티켓을 채우고(MT4의 경우 주문, MT5의 경우 위치) 거래 서버의 반환 코드를 반환합니다.
MT4와 MT5 프로토콜의 차이점에 대해 생각할 필요조차 없습니다. 인터페이스는 필요한 모든 것을 제공합니다.
// СTradeProcessor - переносимый класс торгового процессора// Именно этот класс необходимо использовать для торговли. // Класс реализует интерфейс CTradeProcessorI#ifdef __MQL5__#include <MyLib\Trade\MT5TradeProcessor.mq5>
#else // __MQL5__#include <MyLib\Trade\MT4TradeProcessor.mq5>
#endif //__MQL5__#ifdef __MQL5__class CTradeProcessor : public CMT5TradeProcessor
#else // __MQL5__class CTradeProcessor : public CMT4TradeProcessor
#endif //__MQL5__
{
public :
void CTradeProcessor( uint uiSlippage = DEFAULT_TRADE_POINT_SLIPPAGE);
void ~CTradeProcessor() {};
// Функции отложенных ордеров, которые используют платформоспецифические virtualint PendingDelete(COrderInfoCore* poiOrder);
virtualint PendingModify(COrderInfoCore* poiOrder, double dSetPrice, double dTP= 0 , double dSL= 0 );
};
즉, 플랫폼에 따라 CTradeProcessor 클래스는 CMT5TradeProcessor 클래스 또는 CMT4TradeProceccor 클래스에서 상속됩니다.
물론 이 모든 것은 스위치와 ifdef의 도움으로 OOP 없이 수행할 수 있습니다. 그러나 제 생각에는 OOP 접근 방식이 훨씬 더 편리하고 명확합니다. 그리고 가장 중요한 것은 - 엔터티를 서로 격리하고 대량의 전역 변수를 제거할 수 있다는 것입니다.
그건 그렇고, 예금 작업의 추가 기능에서 "OOP의 반향"이 하나 더 있습니다. 거래 프로세서 - 불편한 지연 티켓과 함께 작동 - MT4 및 MT5의 티켓 액세스가 다릅니다. 따라서 주문 인터페이스의 후속인 공통 클래스 COrderInfoCore가 있습니다. 이 개체에 대한 포인터를 프로세서에 전달하는 것이 훨씬 더 편리합니다. 따라서 같은 방식으로 플랫폼 종속적인 장소를 우회합니다.
예, 그리고 소문에 따르면 Freelance에서는 "MT4와 MT5 모두에서 작업해야"하는 고객의 요구 사항이 매우 빈번하므로 이는 우연이 아닙니다. 나 자신도 프리랜스에서 일할 이유가 없다고 생각하지만 프리랜서에서 일하는 사람들에게 왜 고객이 크로스 플랫폼을 요구하는지 물어볼 수 있습니다.
George Merts : 왜 "실제 내부에서 무슨 일이 일어나고 있는지 이해"해야 합니까? 플랫폼에 관계없이 작업을 수행하는 고정 인터페이스가 있으며 이를 사용합니다. 그리고 낮은 수준에서 무엇이 있습니까? 차이점은 무엇입니까?
우리는 낮은 수준에 대해 이야기하는 것이 아니라 모든 내부 변수에 대한 지식을 포함하여 가능한 모든 순간에 어디에 무엇이 흐르고 무엇으로 변하는지에 대한 논리에 대해 이야기하고 있습니다 ...이 모든 중복 논리를 이해하지 않고 사용의 의미는 작성자가 아닌 사람을 위한 이 코드는 완전히 사라집니다...
이를 위해 MQL4에서는 OOP로 프로그래밍할 수 없으므로 여전히 더 많이 사용됩니다.
나는 이미 내 코드를 보여주었고 다시 보여줄 것이다:
이것은 거래 프로세서 인터페이스입니다. MT4와 MT5 모두에서 동일합니다.
사용자는 이 인터페이스를 수신하기만 하면 됩니다. 그는 거래 활동에 대한 모든 가능성을 가지고 있습니다. 그는 MT4 또는 MT5에서 자신이 어디에 있는지 알 필요조차 없습니다. 구매를 해야 합니다. 구매 기능을 호출하세요. 이것은 당신을 위해 열린 거래 구성 요소의 티켓을 채우고(MT4의 경우 주문, MT5의 경우 위치) 거래 서버의 반환 코드를 반환합니다.
MT4와 MT5 프로토콜의 차이점에 대해 생각할 필요조차 없습니다. 인터페이스는 필요한 모든 것을 제공합니다.
이것들은 모두 OOP의 기능입니다.
나는 이미 내 코드를 보여주었고 다시 보여줄 것이다:
이것은 거래 프로세서 인터페이스입니다. MT4와 MT5 모두에서 동일합니다.
사용자는 이 인터페이스를 수신하기만 하면 됩니다. 그는 거래 활동에 대한 모든 가능성을 가지고 있습니다. 그는 MT4 또는 MT5에서 자신이 어디에 있는지 알 필요조차 없습니다.
그리고 이 모든 것이 OOP 덕분입니다.
일반적인 경우에 대한 사용 예가 있습니까?
이론에 따르면 MQL4=MQL5인 경우 MQL4는 MT5에서 시작될 수 있으며 그 반대의 경우도 마찬가지입니다.
일반적인 경우에 대한 사용 예가 있습니까?
자, 여기에 TP-SL 변경 요청을 거래 프로세서로 보내는 내 기능이 있다고 가정해 보겠습니다.
EEAWorkRetcode CChngTPSLRequest::_ProceedRequestInto(CTradeProcessorI* ptpProcessor) { ASSERT_MYPOINTER(ptpProcessor); m_uiServerRetCode = ptpProcessor.ModifyTPSL(m_lComponentTicket,m_dTP,m_dSL); if (ptpProcessor.TradeOperationWasSuccessful(m_uiServerRetCode) != true ) { Print ( "Торговый запрос на изменение ТП-СЛ компоненты отработал с ошибкой, код возврата: " ,m_uiServerRetCode); TRACE_INTEGER( "Торговый запрос на изменение ТП-СЛ компоненты отработал с ошибкой, код возврата: " ,m_uiServerRetCode); return (WR_SERVER_PROCEED_ERROR); }; return (WR_SUCCEEDED); };첫째, Expert Advisor의 개체 부분은 거래 작업에 대한 요청을 형성합니다(여기에 이러한 요청 중 하나가 - TP-SL 변경에 대한 요청입니다). 그 후 ProceedRequestInto() 함수는 거래 처리자에게 거래 행동에 대한 정보를 보내기 위한 모든 요청에 대해 호출 됩니다.
거래 프로세서 자체는 다음 클래스의 개체입니다.
즉, 플랫폼에 따라 CTradeProcessor 클래스는 CMT5TradeProcessor 클래스 또는 CMT4TradeProceccor 클래스에서 상속됩니다.
물론 이 모든 것은 스위치와 ifdef의 도움으로 OOP 없이 수행할 수 있습니다. 그러나 제 생각에는 OOP 접근 방식이 훨씬 더 편리하고 명확합니다. 그리고 가장 중요한 것은 - 엔터티를 서로 격리하고 대량의 전역 변수를 제거할 수 있다는 것입니다.
그건 그렇고, 예금 작업의 추가 기능에서 "OOP의 반향"이 하나 더 있습니다. 거래 프로세서 - 불편한 지연 티켓과 함께 작동 - MT4 및 MT5의 티켓 액세스가 다릅니다. 따라서 주문 인터페이스의 후속인 공통 클래스 COrderInfoCore가 있습니다. 이 개체에 대한 포인터를 프로세서에 전달하는 것이 훨씬 더 편리합니다. 따라서 같은 방식으로 플랫폼 종속적인 장소를 우회합니다.
자, 여기에 TP-SL 변경 요청을 거래 프로세서로 보내는 내 기능이 있다고 가정해 보겠습니다.
첫째, Expert Advisor의 개체 부분은 거래 작업에 대한 요청을 형성합니다(여기에 이러한 요청 중 하나가 - TP-SL 변경에 대한 요청입니다). 그 후 ProceedRequestInto() 함수는 거래 처리자에게 거래 행동에 대한 정보를 보내기 위한 모든 요청에 대해 호출 됩니다.
내 코드는 MT4 및 MT5에서 완전히 변경되지 않고 실행됩니다.
그리고 왜 다른 터미널에서 실행합니까?
내부에서 무슨 일이 벌어지고 있는지 이해하기엔 너무 복잡한 것 같고... 그리고 작품의 본질을 이해하지 않고서는 사용하지 않을 것 같은... MT5와 필요할 때 연결?
George Merts :
그러나 제 생각에는 OOP 접근 방식이 훨씬 더 편리하고 명확합니다. 그리고 가장 중요한 것은 - 엔터티를 서로 격리하고 대량의 전역 변수를 제거할 수 있다는 것입니다.
필요한 모든 변수의 현재 값을 알아야 할 때 코드를 적절히 디버깅할 수 없다는 것은 말할 것도 없고, 모든 것을 모든 것에서 격리하면 그러한 코드를 처리하는 것이 훨씬 더 어려워진다는 것이 요점입니다. ..
그리고 왜 다른 터미널에서 실행합니까?
그리고 내 메인 계정이 MT4에 열려 있고 MT5 의 전략 테스터 가 훨씬 좋습니다.
예, 그리고 소문에 따르면 Freelance에서는 "MT4와 MT5 모두에서 작업해야"하는 고객의 요구 사항이 매우 빈번하므로 이는 우연이 아닙니다. 나 자신도 프리랜스에서 일할 이유가 없다고 생각하지만 프리랜서에서 일하는 사람들에게 왜 고객이 크로스 플랫폼을 요구하는지 물어볼 수 있습니다.
왜 "실제 내부에서 무슨 일이 일어나고 있는지 이해"해야 합니까? 플랫폼에 관계없이 작업을 수행하는 고정 인터페이스가 있으며 이를 사용합니다. 그리고 낮은 수준에서 무엇이 있습니까? 차이점은 무엇입니까?