당신은 그것을 가지고 있지 않습니다. 모든 오류는 비즈니스 로직에 의해 처리됩니다. MT4에서 synchronicity 속성을 사용하여 처리를 어느 정도 단순화하지만 방법이 모든 경우를 100% 보장하지는 않습니다. 아마도 95% 그리고 전체 거래 프로세스가 구축되는 순전히 당신의 성경입니다. 그러나 MT5는 반환 코드 + 비동기 처리 측면에서 훨씬 더 어렵습니다.
당신은 래퍼에게 불가능한 것을 요구하고 있습니다. 표준 라이브러리는 비즈니스 로직이 아닙니다. 이것은 터미널의 기능을 "오버"하는 래퍼입니다. 사탕 충전물 위에 래퍼입니다. 일부 루틴을 수행하는 사용자 친화적 인 인터페이스입니다. 같은 유형의 코드를 직접 가져옵니다. 당신은 종이 포장을 먹지 않고 그것이 먹을 수 없는 이유를 원망하지 않습니다. :)
그러나 래퍼는 당신이 보증인이기 때문에 아무것도 보장할 수 없습니다. 당신의 비즈니스 논리. 충전재. :) 인쇄 기능과 마찬가지로 디스크 여유 공간을 보장할 수 없습니다. 그리고 로깅 오류. 이렇게 하려면 다른 기능의 오류 처리를 사용해야 하며 해당 기능은 경우에 따라 다릅니다.
질문은 OOP 프로그래밍이 필요한지 여부입니다. 나는 분명히 대답할 수 없다. 내 실습에서는 고급 모델에 OOP를 사용합니다. 물론 기본적으로 기능에 많은 것이 있습니다.
따라서 OOP 클래스를 사용할 때 특정 작업에 대한 추가 항목이 많이 있습니다. 캔버스 드로잉 라이브러리의 기능과 같습니다. 선과 사각형과 텍스트가 있습니다. 그러나 이 클래스에 사각형이 필요한지 여부에 대해 논쟁할 것이 없습니다. 그는 거기에있어. 특정 작업의 경우.
같은 수업에서 풀려고 하는 문제가 너무 많습니다.
당신은 잘못. 그들은 문제를 전혀 해결하지 않습니다. 그들은 일상 을 망쳤습니다. 이해하기 어렵습니까?
따라서 오류 처리는 모든 작업이 해결되어야 합니다.
그녀는 거기에 갈 수 없습니다. 성경은 어떤 문제도 해결하지 않기 때문입니다. ROUTINE을 단순화합니다 . 모든 것. 그녀는 더 이상 할 수 없으며 복잡하지 않으며 그럴 필요도 없습니다.
솔루션은 매우 간단합니다. 해결해야 할 작업에 따라 하나의 성가신 클래스를 여러 개의 작은 클래스로 나눕니다. 이 경우 내 전략에 맞는 수업만 참여하고 그 이상은 참여하지 않습니다. 그리고 지금보다 오류 처리를 구현하는 것이 훨씬 쉬울 것입니다.
더 이상 일상적인 래퍼가 아닙니다. 이것은 이미 Your Expert Advisor의 특정 논리 문제에 대한 솔루션입니다. 하나의 함수(열기 또는 닫기)에서도 오류 처리를 제공하는 것은 불가능합니다. 항상 1001개의 경우가 있을 것입니다. 예측된 오류가 적합하지 않고 다르게 수행되어야 할 때.
모든 상황에 대한 보편적인 기능을 알고 있다면 보여주십시오. 특정 Expert Advisor의 논리를 모르고서 가능한 모든 오류 처리를 미리 예측하는 것이 어떻게 가능한지 상상조차 할 수 없기 때문입니다. 당신이 그런 기능을 한다고 해도 - 그것은 당신의 모든 상위 단어와 모순됩니다 - "또 그들은 팬케이크를 쌓았습니다." .
그리고 방향(ORDER_TYPE_BUY / ORDER_TYPE_SELL)을 고려하여 매크로를 통해 코드를 작성하는 방법을 적용하면 클래스가 매우 간결해집니다. 이 모든 것이 어디 있습니까?
그러나 매크로 에는 오류 처리 기능도 없습니다 . 특정 오류에서 특정 전문가의 비즈니스 논리에 의해 처리됩니다. 보편적인 상황이 없다는 것을 이해하는 것은 그리 어렵지 않습니다.
이제 Renat이 포럼의 제안을 듣는 법을 배웠고 이러한 제안의 의미를 이해하려고 노력했다면 MT5는 이미 이 개발 단계에 있는 현재 상황보다 훨씬 앞서 있었을 것입니다.
Renat는 끊임없이 반복합니다 - 우리는 기술 포럼에 있습니다. 여기서 추상적인 것에 대해 이야기할 수는 없습니다.
그러니 구체적으로 말씀해 주십시오. 참조 조건, 필요한 거래 기능 및 가능한 오류 및 처리 방법을 고려하십시오. 확인?
왜, 나는 나 자신에게 썼지만 네 사람을 위해 썼습니다.
즉, 전문가의 비즈니스 논리와 분리되고 모든 전문가가 사용할 수 있는 범용 라이브러리를 직접 작성했습니까?
나는 이것도 믿지 않는다. 물론 서버 응답 핸들러 코드가 있었지만 범용 라이브러리 형태가 아닌 비즈니스 로직 내부에 모두 있었습니다.
즉, 전문가의 비즈니스 논리와 분리되고 모든 전문가가 사용할 수 있는 범용 라이브러리를 직접 작성했습니까?
나는 이것도 믿지 않는다. 물론 서버 응답 핸들러 코드가 있었지만 범용 라이브러리 형태가 아닌 비즈니스 로직 내부에 모두 있었습니다.
네, 증명할 수 있습니다. 물론 n번째 금액입니다.
즉, MT4용 라이브러리도 없습니다.
그것을 증명하는 것은 그리 어렵지 않았다.
즉, MT4용 라이브러리도 없습니다.
그것을 증명하는 것은 그리 어렵지 않았다.
Renat, 나는 표준 라이브러리의 사용이 "OOP or not OOP"에 속한다는 느낌을 받았습니다.
그렇지 않으면 사람들이 거래 작업을 단순화하는 OOP 래퍼를 사용해서는 안 된다는 강한 믿음을 갖는 이유를 이해할 수 없습니다.
모든 논리를 수행하고, 오류를 처리하고, 요청을 반복하는 등을 수행하도록 래퍼에 대한 일부 클레임 그리고 동시에 그 사용은 위험하다고 주장되며 모든 줄에 오류가 있습니다 ...
저것들. 그녀는.
당신은 그것을 가지고 있지 않습니다. 모든 오류는 비즈니스 로직에 의해 처리됩니다.
MT4에서 synchronicity 속성을 사용하여 처리를 어느 정도 단순화하지만 방법이 모든 경우를 100% 보장하지는 않습니다. 아마도 95% 그리고 전체 거래 프로세스가 구축되는 순전히 당신의 성경입니다.
그러나 MT5는 반환 코드 + 비동기 처리 측면에서 훨씬 더 어렵습니다.
당신은 래퍼에게 불가능한 것을 요구하고 있습니다. 표준 라이브러리는 비즈니스 로직이 아닙니다. 이것은 터미널의 기능을 "오버"하는 래퍼입니다. 사탕 충전물 위에 래퍼입니다.
일부 루틴을 수행하는 사용자 친화적 인 인터페이스입니다. 같은 유형의 코드를 직접 가져옵니다. 당신은 종이 포장을 먹지 않고 그것이 먹을 수 없는 이유를 원망하지 않습니다. :)
그러나 래퍼는 당신이 보증인이기 때문에 아무것도 보장할 수 없습니다. 당신의 비즈니스 논리. 충전재. :)
인쇄 기능과 마찬가지로 디스크 여유 공간을 보장할 수 없습니다. 그리고 로깅 오류. 이렇게 하려면 다른 기능의 오류 처리를 사용해야 하며 해당 기능은 경우에 따라 다릅니다.
-Alexey- , 특정 단점에 대해 이야기하고 수정하고 싶은 특정 단점을 밝힙니다.원하는 경우 각 반환 코드를 살펴보고 가능한 주요 상황을 확인할 수 있습니다.
질문에 답하세요.
- 왜 이 61가지 방법을 모두 끌고 가야 합니까? 합리적입니까?
질문은 OOP 프로그래밍이 필요한지 여부입니다. 나는 분명히 대답할 수 없다.
내 실습에서는 고급 모델에 OOP를 사용합니다.
물론 기본적으로 기능에 많은 것이 있습니다.
따라서 OOP 클래스를 사용할 때 특정 작업에 대한 추가 항목이 많이 있습니다. 캔버스 드로잉 라이브러리의 기능과 같습니다. 선과 사각형과 텍스트가 있습니다. 그러나 이 클래스에 사각형이 필요한지 여부에 대해 논쟁할 것이 없습니다. 그는 거기에있어. 특정 작업의 경우.
같은 수업에서 풀려고 하는 문제가 너무 많습니다.
당신은 잘못. 그들은 문제를 전혀 해결하지 않습니다. 그들은 일상 을 망쳤습니다. 이해하기 어렵습니까?
따라서 오류 처리는 모든 작업이 해결되어야 합니다.
그녀는 거기에 갈 수 없습니다. 성경은 어떤 문제도 해결하지 않기 때문입니다. ROUTINE을 단순화합니다 . 모든 것. 그녀는 더 이상 할 수 없으며 복잡하지 않으며 그럴 필요도 없습니다.
솔루션은 매우 간단합니다. 해결해야 할 작업에 따라 하나의 성가신 클래스를 여러 개의 작은 클래스로 나눕니다.
이 경우 내 전략에 맞는 수업만 참여하고 그 이상은 참여하지 않습니다. 그리고 지금보다 오류 처리를 구현하는 것이 훨씬 쉬울 것입니다.
더 이상 일상적인 래퍼가 아닙니다. 이것은 이미 Your Expert Advisor의 특정 논리 문제에 대한 솔루션입니다.
하나의 함수(열기 또는 닫기)에서도 오류 처리를 제공하는 것은 불가능합니다. 항상 1001개의 경우가 있을 것입니다. 예측된 오류가 적합하지 않고 다르게 수행되어야 할 때.
모든 상황에 대한 보편적인 기능을 알고 있다면 보여주십시오. 특정 Expert Advisor의 논리를 모르고서 가능한 모든 오류 처리를 미리 예측하는 것이 어떻게 가능한지 상상조차 할 수 없기 때문입니다.
당신이 그런 기능을 한다고 해도 - 그것은 당신의 모든 상위 단어와 모순됩니다 - "또 그들은 팬케이크를 쌓았습니다." .
그리고 방향(ORDER_TYPE_BUY / ORDER_TYPE_SELL)을 고려하여 매크로를 통해 코드를 작성하는 방법을 적용하면 클래스가 매우 간결해집니다.
이 모든 것이 어디 있습니까?
그러나 매크로 에는 오류 처리 기능도 없습니다 . 특정 오류에서 특정 전문가의 비즈니스 논리에 의해 처리됩니다. 보편적인 상황이 없다는 것을 이해하는 것은 그리 어렵지 않습니다.
이제 Renat이 포럼의 제안을 듣는 법을 배웠고 이러한 제안의 의미를 이해하려고 노력했다면 MT5는 이미 이 개발 단계에 있는 현재 상황보다 훨씬 앞서 있었을 것입니다.
Renat는 끊임없이 반복합니다 - 우리는 기술 포럼에 있습니다. 여기서 추상적인 것에 대해 이야기할 수는 없습니다.
그러니 구체적으로 말씀해 주십시오. 참조 조건, 필요한 거래 기능 및 가능한 오류 및 처리 방법을 고려하십시오. 확인?
질문에 답하세요:
- 시장가 주문이나 보류 주문만 하면 된다면 이 61가지 방법을 모두 끌고 가야 하는 이유는 무엇입니까? 합리적입니까?
- 포지션이 열려 있고 정지만 설정해야 하는 경우 이 모든 기능을 61개 메서드로 끌어야 하는 이유는 무엇입니까? 합리적입니까?
- 가격이 해당 수준에 도달할 때 발동되는 스탑이 있는 오픈 포지션이 있는 경우 이 61가지 방법을 모두 끌어야 하는 이유는 무엇입니까? 합리적입니까?
아무도 당신을 금지하지 않습니다:
"다른 클래스로 거래 작업 을 위한 별도의 작업"이란 무엇입니까?
열기, 닫기 및 수정에 대해 서로 다른 Expert Advisors가 있는 것과 같습니다. 가능한 것 같지만 아무도 하지 않습니다(드문 예외, 특수 작업 제외).
그리고 저는 "시장가 주문이나 보류 주문을 해야 하는 경우 왜 이 61가지 방법을 모두 끌고 가야합니까? 이것이 합리적입니까?" 라는 문구를 정말 좋아합니다.
글쎄, 한 전문가의 경우 약 100kb의 메모리 오버헤드가 있을 것입니다. 오오오오오오...
그건 그렇고, poll 거래 작업에 표준 라이브러리를 사용합니까?
솔직히 말해서, 나는 헛되이 내 게시물과 함께 나왔습니다.