프로그램을 구성하는 방법을 이해하려면 경험이 필요합니다. 여기에 참석한 사람들 각각은 자신의 경험을 가질 것이며 따라서 구조화의 순서와 규칙은 고유할 것입니다. 또한 이러한 규칙은 시간이 지남에 따라 변경될 것입니다. 즉, 몇 년 전에는 이상적인 구조처럼 보였던 것이 오늘날에는 약간의 비판도 견디지 못할 수 있습니다.
MQL의 프로그램 구조에서는 본질적으로 터미널의 이벤트에 의해 구동되는 DSL이기 때문에 별개의 이야기입니다(지금은 범용 언어로 가져오기 위해 거대한 단계가 수행되었지만). 상태 머신인 IMHO는 거래 전략을 설명하는 가장 좋은 방법이며 이미 이 주제에 대한 여러 기사가 있습니다. 실제로, 구조는 각 케이스의 구현을 위한 많은 포함을 포함하는 큰 케이스로 퇴화합니다.
거래 작업에서 추상화하면 일반적으로 사용자 상호 작용의 세부 사항에 대해 아무것도 모르는 핵심(핵심) 부분을 선택합니다. 그 목표는 스스로 데이터를 채우고, 입력을 기반으로 문제를 해결하고, 결과를 출력하는 방법을 제공하는 것입니다. 커널은 물리적으로 여러 파일로 구성될 수 있지만 모두 논리적으로 연결되어야 하며 외부적으로 데이터를 수신하는 방법과 데이터를 반환하는 방법만 제공하고 다른 것은 제공하지 않습니다. 가장 간단한 비유는 고기 분쇄기입니다.
두 번째로 중요하게 생각하는 것은 변경 가능한 부분(또는 잠재적으로 변경될 수 있는 부분)을 현지화하고 이를 별도의 추상화로 분리하는 것입니다. 이 접근 방식을 사용하면 메커니즘의 다양한 구현 사이를 쉽게 전환할 수 있습니다(예: 오픈 포지션 메커니즘을 전환하여 거래를 가상화할 수 있음). 다양한 구현을 일반 이름으로 별도의 폴더에 넣는 것이 편리합니다.
이 접근 방식을 사용하면 프로젝트 구조가 다양한 관련 하위 시스템(Subsystems)으로 구성된 트렁크(Core)에서 수정된 동작(Behavior)의 분기가 분기되는 트리와 유사합니다. 그리고 그 옆에는 필요한 각도로 이 나무를 보는 쌍안경(보고, GUI)과 이 나무와의 필요한 상호 작용을 제공할 전기톱(액션, GUI)이 있는 도끼가 있습니다.
Представьте на минутку обычного программиста. Допустим, его зовут Вася и ему нужно сделать анимированную менюшку на сайт/десктоп приложение/мобильный апп. Знаете, которые выезжают сверху вниз, как меню у окна Windows или меню с яблочком у OS X. Вот такое. Начинает он с одного выпадающего окошка, тестирует анимацию, выставляет ease out 100% и...
내가 똑똑하다고 생각하지 말고 전투 차량을 작성하기 위한 이 아키텍처 를 다시 살펴보세요. 피드백이 없습니다.
가상 포지션이 있고 가상에 맞게 조정된 실제 거래 환경이 있습니다.
이 경우 플랫폼 또는 다른 회계 시스템의 상계 여부는 중요하지 않습니다.
제 생각에는 특히 일반 테스터에서 테스트할 수 없는 빠른 실행 전략에 대해 매우 흥미로운 구조입니다.
다만 "유능한 싱크로나이저"에 대해서는 완전히 명확하지 않습니다. 이것은 아마도 일종의 적응형 거래 주문 복사기를 의미할 것입니다. 이 작업은 내가 올바르게 이해한다면 전략의 가상 수익성/비수익성과 유동성, 실행 속도 등 시장의 현재 상태를 조정하는 것입니다. .
일반적으로 이러한 테스터와 싱크로나이저는 Expert Advisor에 일체로 장착되지 않고 별도의 외부 모듈로 장착하는 것이 좋습니다.
이 경우 임의의 어드바이저 또는 여러 어드바이저를 동시에 연결하고 가장 적합한 신호를 선택적으로 사용할 수도 있습니다.
MQL 만 사용하여이 작업을 수행 할 수 있는지 궁금합니다 ...
따라서 이것은 별도의 논리 모듈입니다.
예를 들어 신호 서비스 는 차량과 전혀 연결되지 않은 별도의 모듈입니다.
그것은 단순히 소스의 가상 위치(귀하에게 가상임)를 거래 환경으로 전송합니다.
물론 비뚤어진(최적은 아님) 번역하지만.
따라서 이것은 별도의 논리 모듈입니다.
예를 들어 신호 서비스 는 차량과 전혀 연결되지 않은 별도의 모듈입니다.
그것은 단순히 소스의 가상 위치(귀하에게 가상임)를 거래 환경으로 전송합니다.
물론 비뚤어진(최적은 아님) 번역하지만.
비스듬하게 번역하는 Google 번역기가 있지만 이해가 필요하지 않은 경우 이동하고 정확한 것이 필요한 경우 언어를 배우십시오.)
그리고 번역이 좋고 각 고문에 코드를 작성할 필요가 없는 경우 중간 옵션인 개인용 고품질 번역기(모듈)에 만족합니다.
프로그램을 구성하는 방법을 이해하려면 경험이 필요합니다. 여기에 참석한 사람들 각각은 자신의 경험을 가질 것이며 따라서 구조화의 순서와 규칙은 고유할 것입니다. 또한 이러한 규칙은 시간이 지남에 따라 변경될 것입니다. 즉, 몇 년 전에는 이상적인 구조처럼 보였던 것이 오늘날에는 약간의 비판도 견디지 못할 수 있습니다.
MQL의 프로그램 구조에서는 본질적으로 터미널의 이벤트에 의해 구동되는 DSL이기 때문에 별개의 이야기입니다(지금은 범용 언어로 가져오기 위해 거대한 단계가 수행되었지만). 상태 머신인 IMHO는 거래 전략을 설명하는 가장 좋은 방법이며 이미 이 주제에 대한 여러 기사가 있습니다. 실제로, 구조는 각 케이스의 구현을 위한 많은 포함을 포함하는 큰 케이스로 퇴화합니다.
거래 작업에서 추상화하면 일반적으로 사용자 상호 작용의 세부 사항에 대해 아무것도 모르는 핵심(핵심) 부분을 선택합니다. 그 목표는 스스로 데이터를 채우고, 입력을 기반으로 문제를 해결하고, 결과를 출력하는 방법을 제공하는 것입니다. 커널은 물리적으로 여러 파일로 구성될 수 있지만 모두 논리적으로 연결되어야 하며 외부적으로 데이터를 수신하는 방법과 데이터를 반환하는 방법만 제공하고 다른 것은 제공하지 않습니다. 가장 간단한 비유는 고기 분쇄기입니다.
두 번째로 중요하게 생각하는 것은 변경 가능한 부분(또는 잠재적으로 변경될 수 있는 부분)을 현지화하고 이를 별도의 추상화로 분리하는 것입니다. 이 접근 방식을 사용하면 메커니즘의 다양한 구현 사이를 쉽게 전환할 수 있습니다(예: 오픈 포지션 메커니즘을 전환하여 거래를 가상화할 수 있음). 다양한 구현을 일반 이름으로 별도의 폴더에 넣는 것이 편리합니다.
이 접근 방식을 사용하면 프로젝트 구조가 다양한 관련 하위 시스템(Subsystems)으로 구성된 트렁크(Core)에서 수정된 동작(Behavior)의 분기가 분기되는 트리와 유사합니다. 그리고 그 옆에는 필요한 각도로 이 나무를 보는 쌍안경(보고, GUI)과 이 나무와의 필요한 상호 작용을 제공할 전기톱(액션, GUI)이 있는 도끼가 있습니다.
개발자 서비스의 단순 상태 머신
개발자 서비스의 단순 상태 머신
우리의 현실과 관련하여 최소한 대략적인 예를 들어 주십시오.
글쎄, 당신은 제공합니다 :) 모든 전략의 구현은 본질적으로 상태 머신입니다.
이것은 분명합니다. 나는 habra에 관한 기사에 비추어 그러한 기계의 예를 물었습니다.
아, 알았어. ))) 한 친구가 상태 기계의 "아날로그"를 만든 기사가있었습니다. 그리고 그는 이 기술을 프로그래밍 분야의 진보된 발견으로 밀어붙였습니다.)
그리고 여기 상태 머신에 대한 주제 기사가 기억나지 않습니다.
우리의 현실과 관련하여 최소한 대략적인 예를 들어 주십시오.
아하하, "당신의 증거가 무엇인지" 상기시켰습니다 (c)
방금 "상태 머신"을 검색하여 내가 가장 좋아하는 콘텐츠를 선택하고 여기에 업로드했습니다.
나는 아무것도 증명하지 않으며, 아무것도 반증하지 않습니다. 흥미로운 기사.
일반적으로 나는 교리에 반대합니다. 한 사람이 그것을 사용한다고 해서 그것이 다른 사람에게 적합하다는 의미는 아닙니다.
그러나 다른 사람들의 코드를 읽을 때 종종 상태 머신과 유사한 점을 발견합니다. 그냥 관찰입니다.