나는 5년 전, 그 당시 MT4에서 이 길을 따랐습니다. (OOP에 대해 몰랐기 때문이 아니라 인터페이스와 상속을 귀찮게 하기에는 너무 게으르다. 특히 그 당시 MT4와 MT5는 MQL 구현 측면에서 크게 다르기 때문에). 이것은 그가 틀렸다는 것을 깨닫게 했습니다. 이것은 "복잡함"이 아니라 상당히 합리적인 제한, 일종의 "바보에 대한 보호"입니다. 수백 개의 변수 각각이 무엇을 담당하는지 항상 기억한다면 캡슐화가 필요하지 않습니다. 나는 이것을 기억하지 못한다. 그리고 나는 프로그램의 각 블록에서 가능한 한 적은 수의 엔티티에 접근하는 것을 선호한다.
OOP가 MT4에 등장하자마자 나는 인터페이스를 기반으로 모든 개발을 단일 형식으로 즉시 번역하기 시작했습니다.
나는 MQL4 주문 시스템보다 더 편리한 것을 생각해내지 못했습니다. 예시가 있다면 보여주세요.
내가 본 모든 거래 API는 MQL4에 비해 괴물처럼 보입니다. 게다가 그들은 또한 서투르다.
나는 MQL4 주문 시스템보다 더 편리한 것을 생각해내지 못했습니다. 예시가 있다면 보여주세요.
내가 본 모든 거래 API는 MQL4에 비해 괴물처럼 보입니다. 게다가 그들은 또한 서투르다.
뭐라고요 ?
거래 주문의 본질? 예, 매우 편리합니다.
그러나 이 시스템에 OOP를 적용하는 것만으로도 제 생각에는 가장 큰 "이득"을 얻을 수 있습니다. 동일한 인터페이스가 있다고 가정해 보겠습니다. 작업 조건이 헤지 또는 네팅인지 여부에 관계없이 주문으로 구성된 MT4 위치와 MT5 위치로 구성된 MT5 위치를 모두 제공합니다.
제 생각에는 Select() 함수로 얻은 주문 개체(또는 MT5 위치) 목록이 있고 " 환경 상태 "( 같은 함수) , 함수를 통해 액세스합니다.
가장 흥미로운 점은 한 번에 여러 주문을 추적해야 하는 경우입니다. 여기서 절차적 접근 방식은 필연적으로 "의사 객체"로 이어집니다. 주문에 대한 정보 배열을 생성해야 합니다. OnTick()을 사용하고 배열의 인덱스별로 주문 데이터를 사용합니다. 이는 개체를 주문하기 위한 OOP 포인터와 동일합니다.
또한, 과거 주문의 인터페이스가 현재 주문의 후계자이기 때문에 OOP 접근 방식은 역사적 주문과 활성 주문과 동시에 작업할 때 승리합니다. 대부분의 기능은 공유됩니다. 그리고 절차적 접근 방식을 사용하면 과거 및 활성 주문에 다른 기능이 액세스하므로 훨씬 덜 편리합니다.
그러나 이 시스템에 OOP를 적용하는 것만으로도 제 생각에는 가장 큰 "이득"을 얻을 수 있습니다. 동일한 인터페이스가 있다고 가정해 보겠습니다. 작업 조건이 헤지 또는 네팅인지 여부에 관계없이 주문으로 구성된 MT4 위치와 MT5 위치로 구성된 MT5 위치를 모두 제공합니다.
당신은 당신의 포장지를 가지고 있고, 다른 하나는 그의 포장지를 가지고 있습니다. 질문은 달랐습니다. MQL4보다 더 편리한 래퍼를 만들 수 있습니까?
제 생각에는 Select() 함수로 얻은 주문 개체(또는 MT5 위치) 목록이 있고 " 환경 상태 "( 같은 함수) , 함수를 통해 액세스합니다.
가장 흥미로운 점은 한 번에 여러 주문을 추적해야 하는 경우입니다. 여기서 절차적 접근 방식은 필연적으로 "의사 객체"로 이어집니다. 주문에 대한 정보 배열을 생성해야 합니다. OnTick()을 사용하고 배열의 인덱스별로 주문 데이터를 사용합니다. 이는 개체를 주문하기 위한 OOP 포인터와 동일합니다.
이전에 이것에 대해. 게시물을 작성했습니다.
또한, 과거 주문의 인터페이스가 현재 주문의 후계자이기 때문에 OOP 접근 방식은 역사적 주문과 활성 주문과 동시에 작업할 때 승리합니다. 대부분의 기능은 공유됩니다. 그리고 절차적 접근 방식을 사용하면 과거 및 활성 주문에 다른 기능이 액세스하므로 훨씬 덜 편리합니다.
글쎄, MQL4에서 히스토리는 동일한 기능을 통해 처리됩니다(OrdersHistoryTotal은 계산되지 않음).
자신의 거래 API가 MQL4-API보다 분명히 더 나은 코드 예제가 있으면 좋을 것입니다. 나는 거의 모든 곳에서 OOP를 사용합니다. 그리고 몇 가지 특정 문제를 해결하기 위해 거래 래퍼를 만듭니다. 그러나 특정 작업에 사용하는 것이 매우 편리하지만 보편적이지 않습니다. 그러나 여전히 범용 거래 API를 비교하고 싶습니다.
내 연습은 결국 그것이 필요하다는 것을 보여줍니다.
나는 5년 전, 그 당시 MT4에서 이 길을 따랐습니다. (OOP에 대해 몰랐기 때문이 아니라 인터페이스와 상속을 귀찮게 하기에는 너무 게으르다. 특히 그 당시 MT4와 MT5는 MQL 구현 측면에서 크게 다르기 때문에). 이것은 그가 틀렸다는 것을 깨닫게 했습니다. 이것은 "복잡함"이 아니라 상당히 합리적인 제한, 일종의 "바보에 대한 보호"입니다. 수백 개의 변수 각각이 무엇을 담당하는지 항상 기억한다면 캡슐화가 필요하지 않습니다. 나는 이것을 기억하지 못한다. 그리고 나는 프로그램의 각 블록에서 가능한 한 적은 수의 엔티티에 접근하는 것을 선호한다.
OOP가 MT4에 등장하자마자 나는 인터페이스를 기반으로 모든 개발을 단일 형식으로 즉시 번역하기 시작했습니다.
나는 MQL4 주문 시스템보다 더 편리한 것을 생각해내지 못했습니다. 예시가 있다면 보여주세요.
내가 본 모든 거래 API는 MQL4에 비해 괴물처럼 보입니다. 게다가 그들은 또한 서투르다.
나는 MQL4 주문 시스템보다 더 편리한 것을 생각해내지 못했습니다. 예시가 있다면 보여주세요.
내가 본 모든 거래 API는 MQL4에 비해 괴물처럼 보입니다. 게다가 그들은 또한 서투르다.
좋은 점은 각 매개변수를 별도의 함수로 가져와야 한다는 것입니다. 틱과 마찬가지로 요청 시 모든 매개변수가 있는 구조를 수신하는 것이 논리적입니다.
나는 MQL4 주문 시스템보다 더 편리한 것을 생각해내지 못했습니다. 예시가 있다면 보여주세요.
내가 본 모든 거래 API는 MQL4에 비해 괴물처럼 보입니다. 게다가 그들은 또한 서투르다.
뭐라고요 ?
거래 주문의 본질? 예, 매우 편리합니다.
그러나 이 시스템에 OOP를 적용하는 것만으로도 제 생각에는 가장 큰 "이득"을 얻을 수 있습니다. 동일한 인터페이스가 있다고 가정해 보겠습니다. 작업 조건이 헤지 또는 네팅인지 여부에 관계없이 주문으로 구성된 MT4 위치와 MT5 위치로 구성된 MT5 위치를 모두 제공합니다.
제 생각에는 Select() 함수로 얻은 주문 개체(또는 MT5 위치) 목록이 있고 " 환경 상태 "( 같은 함수) , 함수를 통해 액세스합니다.
가장 흥미로운 점은 한 번에 여러 주문을 추적해야 하는 경우입니다. 여기서 절차적 접근 방식은 필연적으로 "의사 객체"로 이어집니다. 주문에 대한 정보 배열을 생성해야 합니다. OnTick()을 사용하고 배열의 인덱스별로 주문 데이터를 사용합니다. 이는 개체를 주문하기 위한 OOP 포인터와 동일합니다.
또한, 과거 주문의 인터페이스가 현재 주문의 후계자이기 때문에 OOP 접근 방식은 역사적 주문과 활성 주문과 동시에 작업할 때 승리합니다. 대부분의 기능은 공유됩니다. 그리고 절차적 접근 방식을 사용하면 과거 및 활성 주문에 다른 기능이 액세스하므로 훨씬 덜 편리합니다.
좋은 점은 각 매개변수를 별도의 함수로 가져와야 한다는 것입니다. 틱과 마찬가지로 요청 시 모든 매개변수가 있는 구조를 수신하는 것이 논리적입니다.
Order.TakeProfit 및 OrderTakeProfit() 항목은 동일합니다. 첫 번째는 개체를 저장하는 기능만 있고 두 번째는 관련성입니다. 나는 차량이 아닌 매우 드물게 보관의 필요성을 충족 시켰습니다. 그리고 생성할 구조가 있습니다. 문제가 없습니다.
개발자들이 왜 주문 구조를 반환하지 않고 함수를 통해 각 필드를 따로 남겨두는지 스스로도 궁금했다(히스토리를 위해서는 매번 티켓도 필요하다).
일반적으로 MQL4-API에서 실제로 나쁜 점은 보이지 않습니다(MT4/5에서만 작동할 수 있음).
뭐라고요 ?
거래 주문의 본질? 예, 매우 편리합니다.
그러나 이 시스템에 OOP를 적용하는 것만으로도 제 생각에는 가장 큰 "이득"을 얻을 수 있습니다. 동일한 인터페이스가 있다고 가정해 보겠습니다. 작업 조건이 헤지 또는 네팅인지 여부에 관계없이 주문으로 구성된 MT4 위치와 MT5 위치로 구성된 MT5 위치를 모두 제공합니다.
당신은 당신의 포장지를 가지고 있고, 다른 하나는 그의 포장지를 가지고 있습니다. 질문은 달랐습니다. MQL4보다 더 편리한 래퍼를 만들 수 있습니까?
제 생각에는 Select() 함수로 얻은 주문 개체(또는 MT5 위치) 목록이 있고 " 환경 상태 "( 같은 함수) , 함수를 통해 액세스합니다.
가장 흥미로운 점은 한 번에 여러 주문을 추적해야 하는 경우입니다. 여기서 절차적 접근 방식은 필연적으로 "의사 객체"로 이어집니다. 주문에 대한 정보 배열을 생성해야 합니다. OnTick()을 사용하고 배열의 인덱스별로 주문 데이터를 사용합니다. 이는 개체를 주문하기 위한 OOP 포인터와 동일합니다.
이전에 이것에 대해. 게시물을 작성했습니다.
또한, 과거 주문의 인터페이스가 현재 주문의 후계자이기 때문에 OOP 접근 방식은 역사적 주문과 활성 주문과 동시에 작업할 때 승리합니다. 대부분의 기능은 공유됩니다. 그리고 절차적 접근 방식을 사용하면 과거 및 활성 주문에 다른 기능이 액세스하므로 훨씬 덜 편리합니다.
글쎄, MQL4에서 히스토리는 동일한 기능을 통해 처리됩니다(OrdersHistoryTotal은 계산되지 않음).
자신의 거래 API가 MQL4-API보다 분명히 더 나은 코드 예제가 있으면 좋을 것입니다. 나는 거의 모든 곳에서 OOP를 사용합니다. 그리고 몇 가지 특정 문제를 해결하기 위해 거래 래퍼를 만듭니다. 그러나 특정 작업에 사용하는 것이 매우 편리하지만 보편적이지 않습니다. 그러나 여전히 범용 거래 API를 비교하고 싶습니다.
개발자들이 왜 주문 구조를 반환하지 않고 함수를 통해 각 필드를 따로 남겨두는지 스스로도 궁금했다(히스토리를 위해서는 매번 티켓도 필요하다).
Alexey Volchanskiy :
Дело в том, что в МТ4 до 600-го билда не было структур )) А новый MQL4 появился где-то в начале 2013 г.
MT5에는 구조가 있지만 어쨌든 함수를 통해 반환됩니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
OOP에 대한 간접비
fxsaber , 2017.07.07 08:08
질문은 달랐습니다. MQL4보다 더 편리한 래퍼를 만들 수 있습니까?
MT5에는 구조가 있지만 어쨌든 함수를 통해 반환됩니다.
비록 헛된 것이지만 아마도 전통을 깨뜨리지 않기로 결정했을 것입니다.
또한 DC 서버에서 데이터를 다운로드했지만 로컬 데이터인 경우 즉시 가져와 구조를 즉시 채울 수 있다는 것도 이해합니다.
비록 헛된 것이지만 아마도 전통을 깨뜨리지 않기로 결정했을 것입니다.
또한 DC 서버에서 데이터를 다운로드했지만 로컬 데이터인 경우 즉시 가져와 구조를 즉시 채울 수 있다는 것도 이해합니다.
예, 내부에 SELECT를 사용하면 const(읽기 전용) 함수를 통해서만 해당 필드에 도달할 수 있는 숨겨진 구조의 한 인스턴스를 정확하게 채우는 것입니다.
이것은 아마도 거래 API 코어의 유일한 논란의 여지가 있는 결정일 것입니다. 그 외에는 무엇에 대해 불평해야 할지조차 모르겠습니다.
예, 내부에 SELECT를 사용하면 const(읽기 전용) 함수를 통해서만 해당 필드에 도달할 수 있는 숨겨진 구조의 한 인스턴스를 정확하게 채우는 것입니다.