기고글 토론 "MQL5 객체 지향 프로그래밍 접근 방식을 사용한 Expert Advisor 작성하기"

 

새로운 기고글 MQL5 객체 지향 프로그래밍 접근 방식을 사용한 Expert Advisor 작성하기 가 게재되었습니다:

이 글은 "초보자를 위한 MQL5에서 Expert Advisor를 작성하기 위한 단계별 가이드" 글에서 수행 한 작업에 대한 객체 지향 접근 방식에 초점을 맞추고 있습니다. 대부분의 사람들은 이것이 어렵다고 생각하지만, 이 글을 다 읽고 나면 객체 지향 기반의 Expert Advisor를 직접 작성할 수 있을 것임을 확신하고 싶습니다.

그래서 다음은 무엇입니까? 

디버그라는 말을 들었나요? 항상 테스트하고 코드에 오류가 있는지 확인하는 것이 좋습니다. 그렇지 않으면 공개 할 때 실망하게 됩니다. 여기서 문제는 이것이 단지 포함 파일이며, 차트에 첨부 할 수있는 Expert Advisor 코드 나 스크립트 또는 인디케이터 코드가 아니라는 것입니다. 이 시점에서 두 가지 옵션이 있습니다 (제 경험상).,

  • .mqh 파일 때문에 표시되는 '실행 파일이 생성되지 않음' 오류를 제외하고 디버거가 코드의 오류를 보고하도록 편집기의 디버그 버튼을 누를 위험이 있습니다.ex5 파일로 컴파일 할 수 없습니다. 또는
  • 계속해서 클래스를 사용할 EA 코드를 작성하십시오. EA 디버깅을 시작하면 포함 된 파일도 함께 확인됩니다. 사실, 이것이 최선의 방법이고 가장 수용 가능한 방법입니다.

작성자: Samuel Olowoyo

 

일반적으로 나쁘지는 않지만 이름에 사용된 OOP 슬로건을 따르는 데는 다소 아쉬움이 있습니다. 예를 들어 스톱로스, 테이크, 가격이 클래스 외부에 배치된 이유는 무엇인가요? STP와 TKP는 멤버가 되어야 하고, setSLTP 메서드가 필요하며, 최신_가격과 수준은 openBuy/openSell 내부에서 고려해야 합니다. 그 자체는 매우 비합리적으로 작성되어 있습니다. MarginOK 호출을 사용하는 경우 하나만 남겨두고 그 안에 if(Chk_Margin == 0) return(true) 확인의 첫 번째 줄을 추가하는 것이 바람직합니다;

그리고 한 가지 더 있습니다. Chk_Margin은 부울로만 사용되는데 왜 int-로 선언되어 있을까요? 최소한의 충분한 유형으로 설명하는 것이 더 좋을 것입니다. 그렇지 않으면 소스 코드를 읽을 때 Chk_Margin == 2, 3 등이 발생하면 어떻게 될까요?

 
기본 입력 매개 변수를 사용하여 지정된 기간에 지정된 쌍을 사용하면 이렇게 아름다운 잔액 차트를 얻을 수 없습니다. 작성자에게 다른 따옴표가 있었나요? 그러한 차트를 얻은 입력 매개 변수를 첨부해 주시겠습니까?
 
capr:
기본 입력 매개 변수를 사용하여 지정된 기간에 지정된 쌍을 사용하면 이렇게 아름다운 잔액 차트를 얻을 수 없습니다. 작성자에게 다른 따옴표가 있었나요? 그러한 차트를 얻은 입력 매개 변수를 첨부해 주시겠습니까?

결과가 매우 달라지려면 귀하와 작성자 간의 따옴표가 얼마나 달라야합니까))))))) 나는 거의 똑같이 얻었고 최종 결과는 조금 더 좋습니다:

 

디자인이 수수께끼입니다.

   if(Buy_Condition_1 && Buy_Condition_2 && Buy_Condition_3 && Buy_Condition_4)
     {
       return(true);
     }
     else
     {
       return(false);
     }
 
ortv:

디자인이 수수께끼입니다.

정확히 무엇이 그렇게 싫으신가요? 물론, 코드의 맥락에서 본 적이 없습니다....
 
Interesting:
정확히 무엇이 그렇게 싫으신가요? 물론, 나는 코드의 맥락에서 그것을 보지 못했습니다.....

이런 경우에는 보통 그렇게 작성하지 않나요?

return(Buy_Condition_1 && Buy_Condition_2 && Buy_Condition_3 && Buy_Condition_4);
 
ortv:

이런 경우 보통 이렇게 작성하지 않나요?

코드가 정확히 재현되고 처리에 다른 것이 없다면 이렇게 할 수 있습니다...
 

코드의 다음 부분이 이해가 되지 않습니다:

// 이전 막대(막대 1)의 종가를 해당 전문가 조언자 변수에 복사합니다.
   Cexpert.setCloseprice(mrate[1].close);  // 바 1 종가
//--- 매수 포지션이 있는지 확인
   if (Cexpert.checkBuy()==true)
   {
      if (Buy_opened) 
         {
            Alert("우리는 이미 매수 포지션이 있습니다!!!"); 
            return;    // 롱 포지션에 추가하지 마십시오.
         }
      double aprice = NormalizeDouble(latest_price.ask,_Digits);
      double stl    = NormalizeDouble(latest_price.ask - STP*_Point,_Digits);
      double tkp    = NormalizeDouble(latest_price.ask + TKP*_Point,_Digits);
      int    mdev   = 100;
      // 주문하기
      Cexpert.openBuy(ORDER_TYPE_BUY,Lot,aprice,stl,tkp,mdev);
   }
매수 포지션을 오픈하려면 최신_가격.매도 호가에 초점을 맞춰야 하지만, 해당 포지션에 손절매와 이익실현을 설정할 때는 최신_가격.매수 호가에 초점을 맞춰야 합니다. 이것이 맞나요? 코드 텍스트의 매도 호가를 기준으로 손절매와 이익실현이 설정되는 이유는 무엇인가요? 오기인가요, 아니면 특정 전략의 특성인가요(매도 포지션을 개설할 때 코드 구조가 비슷합니다)?
 
Yedelkin:

코드의 다음 부분이 이해가 되지 않습니다:

매수 포지션을 오픈하려면 최신_가격.매도 호가에 초점을 맞춰야 하지만, 해당 포지션에 손절매와 이익실현을 설정할 때는 최신_가격.매수 호가에 초점을 맞춰야 합니다. 이것이 맞나요? 그렇다면 왜 코드 텍스트의 매도 호가를 기준으로 손절매와 이익실현이 설정되나요? 오기인가요 아니면 특정 전략의 특성인가요(코드가 매도 포지션 개설과 유사한 구조를 가지고 있음)?

로직은 다음과 같습니다(아마 저도 보통 이 로직을 사용합니다):

1. 매수 개시가는 매도 호가로 간주합니다(그리고 이는 맞습니다);

EURUSD에서 1.27에 개시한다고 가정해 봅시다.

2. 포지션을 개시할 때 스프레드와 동일한 차액이 발생하며, 매수의 경우 매도-매수(현재 가격으로 청산하면 잠재적 손실)입니다;

스프레드가 5핍이라고 가정해 봅시다. 따라서 개장 시 입찰가는 1.2695가 됩니다(맞죠?).

3. 롱 포지션은 매수호가에 청산됩니다(이는 매우 논리적입니다).

따라서 Bid가 1.27에 도달하면 포지션에 BU가 발생합니다(맞죠?).

4. 하지만 수익도 얻어야 합니다(표준 호가에서 100핍).

즉, TP가 Open보다 100핍 높아야 합니다. 저희의 경우 1.28입니다(맞죠?).

동시에 Bid (Ask가 아닌)가이 1.28에 도달하면 TP가 트리거됩니다....

5. SL도 설정해야 합니다(50핍이라고 가정해 보겠습니다). 따라서 이 예에서는 1.2650(시가보다 50핍 아래)에 위치하게 됩니다.

SL은 어떤 조건에서 작동하나요?

논리적으로 가격이 바로 이 50핍을 통과할 때 작동합니다(즉, SL의 종가 코인이 논리적으로 바로 이 1.2650에 있을 때 요청해야 합니다).

이 경우 입찰은 어디에 있어야 하나요? 현재 1.2645에 위치할 것입니다(스프레드는 5핍이 있기 때문에).

롱은 고정되어 있다는 것을 기억하세요.

6. 이제 실제로 어떤 일이 일어나는지 살펴봅시다(MQL4에서 매수 포지션의 시장가를 예로 들어 보겠습니다).

//Взято из справки по OrderSend
 ticket=OrderSend(Symbol(),OP_BUY,1,Ask,3,Bid-25*Point,Ask+25*Point);

여기서 볼 수 있는 것은 다음과 같습니다.

시가는 매도 호가, SL은 매수 호가, TP는 매도 호가로 간주됩니다.

우리의 경우 이 패턴을 얻을 수 있습니다.

OrderSend(Symbol(),OP_BUY,1,Open = Ask,3,SL = Bid-50*Point,TP Ask+100*Point);

여기에 데이터를 대입해 보겠습니다:

OrderSend(Symbol(),OP_BUY,1,1.2700,3,1.2695-50*Point,TP 1.2700+100*Point);

최종 결과 - Open = 1.2700 SL = 1.2645 TP 1.28

PS

원본 데이터와 비교해 보겠습니다:

주문 - Open = 1.2700 SL = 1.2645 TP 1.28

모델 - 오픈 = 1.2700 SL = 1.2645 TP 1.28

 
Interesting:

여기에는 이런 논리가 있습니다(대부분 저도 이 논리를 사용하는 경향이 있습니다):

1. Buy의 시초가는 Ask로 간주됩니다(그리고 이는 맞습니다);

EURUSD에서 1.27에 개시한다고 가정해 보겠습니다.

2. 포지션을 개시하면 스프레드와 동일한 차액이 발생하며 매수의 경우 매도-매수(현재 가격으로 청산할 경우 잠재적 손실)가 발생합니다;

스프레드가 5핍이라고 가정해 봅시다. 따라서 개장 시 입찰가는 1.2695가 됩니다(맞죠?).

5. SL도 설정해야 합니다(50핍이라고 가정해 보겠습니다). 따라서 이 예제에서는 1.2650(Open보다 50핍 아래)에 위치하게 됩니다.

SL은 어떤 조건에서 발동되나요?

논리적으로 가격이 바로 이 50핍을 통과할 때 작동합니다(즉, SL의 종가 코인 요청은 논리적으로 바로 이 1.2650에 있어야 합니다).

이 경우 입찰은 어디에 있어야 하나요? 현재 1.2645에 위치할 것입니다(스프레드는 5핍이 있기 때문에).

롱은 고정되어 있다는 것을 기억하세요.

개장 시 입찰가가 1.2695에 있다면 이미 5핍의 손실이 자동으로 발생합니다. 동시에 개발자의 아이디어에 따라 SL이 50핍이라면, 스톱이 발동되기 전에 불리한 방향으로 45핍을 더 이동해야 합니다. 즉, 스톱로스가 발동될 때 입찰가는 1.2645가 아니라 1.2650에, 매도가는 1.2655에 각각 설정해야 합니다.