위치 추적 및 돈 및 위험 관리 모듈에서 신호 모듈의 Direction() 메서드에 의해 반환된 값 읽기에 대한 공개 액세스.
저것들. 예를 들어, 신호 모듈 클래스의 인스턴스를 참조하고 결과로 Direction() 메서드의 결과를 반환하는 식별자 double getMainSingnal()을 사용하여 위치 추적 및 돈 및 위험 관리 모듈에 메서드를 하나 더 추가합니다. 신호 모듈. 이 정보 교환은 읽기 전용 모드에서 이루어지므로 보안이 어떤 식으로든 손상되지 않습니다.
이를 위해 당신이 필요합니다
CExpertMoney 및 CExpertTrailing 클래스에서 필드를 선택하여 CExpertSignal 클래스의 인스턴스를 저장합니다. 메인 신호 모듈.
CExpertSignal 클래스의 바로 이 인스턴스, 즉 신호 모듈은 이러한 동일한 모듈의 클래스 인스턴스를 초기화하는 동안 위치 추적 및 돈 및 위험 관리 모듈로 전송되어야 하며 1절에 지정된 필드에 저장되어야 합니다. 당연히 이 작업을 수행하기 전에 신호 모듈 클래스의 인스턴스가 이미 존재하는지 확인(확인)해야 합니다. 생성되었습니다.
CExpertMoney 및 CExpertTrailing 클래스에서 클래스의 해당 데이터 필드에 저장된 신호 모듈 클래스의 인스턴스에 액세스하고 신호의 Direction() 메서드 결과를 반환하는 식별자 double getMainSingnal()을 사용하여 추가 메서드를 만듭니다. 기준 치수.
거의 모든 것이 명확합니다. 내가 명확히 하고 싶은 것은 "MM 수준에서 신호를 보고자 하는 욕구와 후행을 기본 클래스 수준에서 구현해야 하는 이유는 무엇입니까?"입니다.
나는 그것이 나쁠 것이라고 생각합니다(즉, 나쁨). 알고리즘은 일반적이지 않습니다(내 관점에서). 내가 이해하는 한, 당신은 자신의 MM과 후행 모듈을 가지고 있습니다(자신의 알고리즘이 신호에 연결되어 있음).
각 후행 전에 호출되는 메소드의 맨 처음에 삽입하십시오. CheckTrailingStop():
bool CExpert::CheckTrailingStop()
{
//--- Set signal direction to trailing stops module
m_trailing.setSignalDirection(m_signal.Direction());//--- position must be selected before callif (m_position.PositionType()== POSITION_TYPE_BUY )
{
//--- check the possibility of modifying the long positionif (CheckTrailingStopLong()) return ( true );
}
else
{
//--- check the possibility of modifying the short positionif (CheckTrailingStopShort()) return ( true );
}
//--- return without operationsreturn ( false );
}
bool CExpert::CheckOpen()
{
//--- set signal direction to money management module
m_money.setSignalDirection(m_signal.Direction());if (CheckOpenLong()) return ( true );
if (CheckOpenShort()) return ( true );
//--- return without operationsreturn ( false );
}
그게 다야, 문제가 해결되었습니다.
이제 m_signaldirection 필드 값을 참조하여 위치 추적 및 자금 및 위험 관리 모듈에서 거래 신호의 현재 값을 얻을 수 있습니다. 이제 CExpertMoney 및 CExpertTrailing 클래스에 새 필드와 메서드가 있다는 문서를 작성하고 변경된 파일을 업데이트에 추가하면 됩니다.
다음은 파일입니다. Expert Advisor의 100행과 123행은 손으로 쓴 것입니다.
더 궁금한 사항이 있으시면 연락주세요.
젠장, 이 개발자들은 어떤 사람들입니까? 그들은 언제 이미 거래 시스템을 만든 경험이 있는 거래자가 필요로 하는 것에 귀를 기울이고 소스의 수동 개선이 필요하기 때문에 최종 사용자에게 실질적으로 부적합한 거래 시스템을 구축하는 자신의 비전을 발명하지 않을 것입니까? ? 손으로 올라가서 고칠 수 있다는 걸 얼마나 설명할 수 있겠어. 그러고도 프로그래밍에 익숙함에도 불구하고 무엇을, 왜 그런지 알아내려면 오랜 시간이 걸릴 것이다. 그리고 최종 사용자는 코드에 들어갈 가능성이 낮습니다. 그는 프로그래밍을 이해하지 못합니다. 당신 자신이 다음과 같이 선언했습니다.
그리고 이제 프로그래밍 언어에 대한 지식이 필요하다는 것이 밝혀졌습니다. 사용자는 마법사가 작동한 후 코드로 올라가서 무언가를 편집해야 합니다. 저것들. 모든 선언은 이전 선언 - 개발자의 발명 및 속임수입니다.
예를 들어, 다른 모듈 개발자가 작성한 모듈에서 발행한 거래 신호의 수준에 따라 포지션을 열어야 하는 내 자신의 돈 및 위험 관리 모듈을 작성할 것입니다. 결과적으로 내 모듈이 더 이상 마스터와 호환되지 않는 것으로 나타났습니다. 사용자에게 코드의 어딘가로 이동하고 모듈이 작동하기 시작하도록 몇 줄을 삽입해야 한다고 설명하는 방법은 무엇입니까? 결국 모듈 개발자는 모듈을 생성해야 하고 마스터는 모듈이 최소한 서로 충돌하지 않고 서로 완전히 호환되도록 자동으로 하나의 일관된 시스템으로 결합해야 합니다. 그리고 당신은 주인이 이것을하지 않는다는 것을 알게됩니다. 왜냐하면. 그 후에는 코드로 올라가 모든 것을 수동으로 다시 실행해야 합니다.
지난번 메시지에서 지적한 상위 클래스 파일에 6줄만 쓰는 것이 정말 그렇게 어려운 일입니까? 그리고 그 문제는 저절로 해결될 것이고 아무도 소스 코드에 들어가서 무언가를 편집할 필요가 없을 것입니다. 손이 떨어진다고? 마법사 이후에 수동으로 수정하는 방법을 시연하면서 쓰레기에 시간을 낭비하는 이유는 무엇입니까? 나중에 아무도 유사한 문제를 해결하기 위해 코드에 들어가지 않아도 되도록 이 같은 시간을 더 유용한 일에 할애할 수 없습니까?
당신의 회사는 한편으로 완전 자동화를 선언하는 어떤 종류의 이데올로기를 가지고 있으며, 그것에 관해서는 소위 "자동화"후 코드에 들어가서 펜으로 모든 것을 다시 할 것을 제안합니까?
일반적으로 내가 이해하는 한 이 모든 것은 설명할 수 없습니다. 그리고 플랫폼이 조잡하고 자동 거래의 편의를 위해 만들어진 것이 아니라 바로 이 플랫폼의 개발자의 편의를 위해 만들어졌기 때문에 거래자가 MT5로 전환하기를 원하지 않는다는 사실에 놀랄 일이 아닙니다. 그리고 사용자가 프로그래밍을 철저히 배우지 않으면 가능한 한 자동 거래에서 멀어지는 것이 좋습니다.
원하지 않으면 할 필요가 없습니다. 다른 할 일이 없다면 여기 앉아서 각 사용자에게 펜으로 소스 코드를 입력해야 하는 위치와 방법과 정확히 수정해야 할 사항을 설명하십시오.
Знание языков программирования теперь не является обязательным условием для создания торговых роботов. Если раньше это действительно служило непроходимым препятствием для реализации своих торговых стратегий, то появление Мастера MQL5 в корне изменило ситуацию. Начинающие трейдеры могут перестать тревожиться из-за отсутствия опыта программирования - с новым визардом, позволяющим быстро генерировать код советника, он не понадобится.
Renat : 나는 당신이 극대주의에 사로잡혀 있거나 단순히 도구의 적용 가능성의 한계를 이해하지 못하는 것 같습니다.
어쨌든 그런 수준의 논쟁과 허용 가능한 과장의 한계를 넘어 거의 모든 질문을 제거하면 당신과 함께 할 수 없습니다. 실제 작업에는 구두 선동이 아닌 의식적인 의사 결정이 포함됩니다.
예, 일반적으로 일자리를 구하지 않았습니다. 돈을 벌기 위해, 자발적으로 협력하는 것에 상당히 만족했습니다. 내가 돈을 버는 방법과 장소는 내가 결정합니다.
글쎄요, 그럴 수도 없고 해서도 안 됩니다. 우리의 일은 제안하는 것이고, 당신의 권리는 거절하는 것입니다. 그들이 말했듯이 : 주인은 주인입니다.
회사가 이미 모든 것을 깨닫고 인형에게 소위 "기성품" Expert Advisors를 만드는 방법을 가르쳤고 마법사를 시연하는 데에만 적합하지만 자동 거래에는 적합하지 않은 경우에도 과거 데이터 주식 곡선이 무섭게 보입니다. 모듈화가 제공되지만 본격적인 거래 시스템을 위한 모듈의 일관성이 없다면 나는 당신을 방해하지 않고 거래 시스템이 어떻게 만들어져야 하고 어떻게 만들어져야 하는지에 대한 당신의 기업 비전을 더 홍보하지 않을 것입니다.
예를 들어, 다른 모듈 개발자가 작성한 모듈에서 발행한 거래 신호의 수준에 따라 포지션을 열어야 하는 내 돈 및 위험 관리 모듈 을 작성할 것입니다. 결과적으로 내 모듈이 더 이상 마스터와 호환되지 않는 것으로 나타났습니다. 사용자에게 코드의 어딘가로 이동하고 모듈이 작동을 시작하도록 몇 줄을 삽입해야 한다고 설명하는 방법은 무엇입니까? 결국 모듈 개발자는 모듈을 생성해야 하고 마스터는 모듈이 최소한 서로 충돌하지 않고 서로 완전히 호환되도록 자동으로 하나의 일관된 시스템으로 결합해야 합니다. 그리고 당신은 주인이 이것을하지 않는다는 것을 알게됩니다. 왜냐하면. 그 후에는 코드로 올라가 모든 것을 수동으로 다시 실행해야 합니다.
지난번 메시지에서 지적한 상위 클래스 파일에 6줄만 작성하는 것이 정말 그렇게 어려운가요? 그리고 그 문제는 저절로 해결될 것이고 아무도 소스 코드에 들어가서 무언가를 편집할 필요가 없을 것입니다. 손이 떨어진다고? 마법사 이후에 수동으로 수정하는 방법을 시연하면서 쓰레기에 시간을 낭비하는 이유는 무엇입니까? 나중에 아무도 유사한 문제를 해결하기 위해 코드에 들어가지 않아도 되도록 이 같은 시간을 더 유용한 일에 할애할 수 없습니까?
...
귀하의 접근 방식은 클래스 캡슐화를 깨고 결과적으로 계층적 혼란을 야기합니다.
여가 시간에 Steve McConnell의 책 Perfect Code를 읽으십시오.
간단히 말해 마스터가 장갑을 생산하는 공장이라고 상상해보십시오. 오른손과 왼손에 다섯 손가락 스탬프가 있지만 여섯 손가락 장갑에 대한 작은 주문이 나타납니다. 결국 그런 사람들이 있습니다. 그러나 그들을 위해 우표를 만드는 대신(일괄 처리를 만들고 잠시 동안 거기에 누워 있을 것입니다), 손가락을 움직여서 다섯 손가락 우표를 변경할 것을 제안합니다. 그것은 보편적인 것처럼 보이고 모든 것이 위대하지만 가상의 수백만 개의 다섯 손가락 장갑의 주사위의 힘은 보편성을 위해 약해질 것입니다(작은 필요를 위해 때때로 여섯 손가락 장갑을 풉니 다) . 그런 다음 300 개의 네 손가락 배치에 대한 주문이있을 것이며 잘 입증되고 신뢰할 수있는 템플릿을 다시 무너 뜨릴 것입니다.
당신은 위에서 들었다:
"MM 및 후행 신호를 보고자 하는 욕구가 기본 클래스 수준에서 구현되어야 하는 이유는 무엇입니까?"
나는 그것이 나쁠 것이라고 생각합니다(즉, 나쁨). 알고리즘은 일반적이지 않습니다(내 관점에서). 내가 이해하는 한, 당신은 자신의 MM과 후행 모듈을 가지고 있습니다(자신의 알고리즘이 신호에 연결되어 있음).
표준 성경을 변경하는 것보다 (상속을 통해) 확장하는 작업을 하는 것이 좋습니다. 그러면 정말 흥미로울 것입니다.
추신 또한 사람들이 복잡한 코드를 다룰 필요가 없도록(위에서 설명한 대로) 완성된 모듈을 bibl로 포장하여 시장에 쏟아낸 다음 Reshetov의 모듈을 연결하고 [전리품 다운로드] 버튼
간단히 말해 마스터가 장갑을 생산하는 공장이라고 상상해보십시오. 오른손과 왼손에 다섯 손가락 스탬프가 있지만 여섯 손가락 장갑에 대한 작은 주문이 나타납니다. 결국 그런 사람들이 있습니다. 그러나 그들을 위해 우표를 만드는 대신(일괄 처리를 만들고 잠시 동안 거기에 누워 있을 것입니다), 손가락을 움직여서 다섯 손가락 우표를 변경할 것을 제안합니다. 그것은 보편적인 것처럼 보이고 모든 것이 위대하지만 가상의 수백만 개의 다섯 손가락 장갑의 주사위의 힘은 보편성을 위해 약해질 것입니다(작은 필요를 위해 때때로 여섯 손가락 장갑을 풉니 다) . 그런 다음 300 개의 네 손가락 배치에 대한 주문이 있고 다시 잘 입증되고 안정적인 템플릿이 무너집니다.
당신은 위에서 들었다:
표준 성경을 변경하는 것보다 확장 작업(상속을 통해)하는 것이 좋습니다. 그러면 정말 흥미로울 것입니다.
예, 부모 클래스에서 사용할 수 없는 것을 상속하는 것이 불가능하다고 이미 얼마나 오랫동안 말할 수 있습니까? 같은 Steve McConnell "Perfect Code"의 책을 언제 마침내 알게 될까요?
내 접근 방식은 캡슐화 원칙을 위반하지 않습니다. 내가 제안한 변형에서는 불필요한 모든 것이 숨겨져 있고 모듈은 읽기 모드에서만 이중 값의 형태로 거래 신호만 수신합니다. 다른 사람들과 달리 OOP에 관한 책을 읽을 뿐만 아니라 꼼꼼히 공부했습니다.
나는 템플릿 장갑에 여섯 손가락 장갑을 만들 것을 제안하지 않았습니다. 추가 모듈의 형태로 여섯 번째 손가락을 연결하지만 실제로 거래 시스템의 주요 모듈인 신호 모듈의 신호를 사용하여 기존의 모든 모듈을 조정하도록 제안되었습니다. 전체 시스템은 그의 명령에 따라 작동해야 합니다. 모듈화를 제안한 것은 바로 당신이었습니다. 교체 가능한 손가락이 있는 장갑. 그러나 모든 일을 너희가 하여 오른손이 왼손이 하는 것을 알지 못함이니라. 다른 모듈은 신호 모듈에서 정보를 수신하고 동작을 동기화할 수 없으며 장갑은 다른 크기의 손가락(모듈)으로 얻습니다. 장갑을 착용하면 사용자는 손가락 중 하나가 작고 아무 것도 맞지 않는 것을 봅니다. 그것 , 그리고 다른 하나는 크고 너무 많이 튀어나와 있습니다 .
예를 들어, 후행 정지는 모듈의 타사 개발자가 작성한 일부 별도의 신호 시스템에 따라 실행됩니다. 예를 들어 이동 평균 또는 포물선에 따라 신호가 어떤 지점에서 신호 모듈이 출력하는 것과 모순되고 전체 거래 시스템이 불협화음을 일으키기 시작합니다. 돈 및 위험 관리 모듈은 또한 텔레파시로 거래 신호가 약하다는 것을 추측할 수 없으며 열린 위치의 양을 줄여야 할 때이며 신호 모듈과 독립적인 일부 규칙에 따라 행동합니다. 하나는 회전할 때 속도를 줄이도록 요청하고 다른 하나는 가스를 누릅니다. 그리고 소위 마스터의 도움으로 만들어진 전체 거래 시스템은 "백조, 암 및 파이크"라고 불리는 할아버지 Krylov의 우화처럼 밝혀졌습니다. 그 이상도 그 이하도 아닙니다. 그리고 당신의 회사는 자동차 거래를 위해 무모한 고문을 모으는 이 멋진 이데올로기를 강요하려고 합니다. 그리고 우리는 그것을 필요로합니까?
그러나 이러한 차트의 이유는 모듈 작성자(이 경우 Nikolai Kositsin)가 잘못했기 때문이 아니라 거래 시스템의 다른 모듈이 서로 조정될 수 없고 다르게 작동하기 때문입니다.
그러나 이미 설명하는 것은 무의미합니다. 플랫폼 개발자는 문제를 해결하는 불행한 6줄을 작성하는 대신 포럼에 긴 발판을 작성하고 거래 시스템 개발자가 선동을 퍼뜨리고 캡슐화 원칙을 위반하는 등 치명적인 죄를 지었다고 비난하지만, 자신의 결점과 오해를 바로잡는 손가락.
따라서 더 이상의 논의는 무의미하다. 자신의 의견을 고수하고 원하는 대로 행동하십시오. 나는 이미 피곤하고 아무 소용이 없기 때문입니다. 플랫폼 개발자는 자신이 사용하지 않는 공예품을 뻔뻔하게 이야기하고 자동 거래 플랫폼 사용자가 동일한 공예품을 사용할 수 있는지 여부를 신경 쓰지 않습니다. 개발자는 전혀 신경 쓰지 않습니다. 배고픈 사람은 배고픈 사람을 이해하지 못합니다.
Reshetov, 나는 당신의 이 신발류도 감정으로 읽을 수 있습니다. 논쟁하고 싶다면 논쟁하십시오.
마법사의 핵심은 거래자의 대부분의 요구 사항을 충족하는 템플릿을 만드는 것입니다. 웜에는 어드바이저 템플릿이 있으며(직접 작성했습니다), 이는 주요 기능을 설정합니다. 그리고 실제로는 항상 수정되어야 합니다. 그러나 편집은 최소화됩니다. 전혀 편집하지 않도록 템플릿을 만들면 익사할 수 있는 모든 경우에 거대한 코드가 될 것입니다.
마스터는 이미 작동하고 있는 템플릿을 생성하고, 프로그래밍을 전혀 할 줄 모르는 사람도 그대로 사용할 수 있습니다. 코딩을 이해한다면 원하는 방식으로 변경하는 것은 어렵지 않습니다. 표준 성경에서 어떤 것이 어디서 왔으며 모든 것이 어디로 가는지 이해하는 것은 한 번이면 충분합니다. 또한 표준 성경도 샘플로 사용할 수 있으며 원하는 섹션을 코드에 복사하여 붙여넣을 수 있습니다.
지금까지 위의 단점을 제거할 수 있는 것은 단 하나뿐입니다.
위치 추적 및 돈 및 위험 관리 모듈에서 신호 모듈의 Direction() 메서드에 의해 반환된 값 읽기에 대한 공개 액세스.
저것들. 예를 들어, 신호 모듈 클래스의 인스턴스를 참조하고 결과로 Direction() 메서드의 결과를 반환하는 식별자 double getMainSingnal()을 사용하여 위치 추적 및 돈 및 위험 관리 모듈에 메서드를 하나 더 추가합니다. 신호 모듈. 이 정보 교환은 읽기 전용 모드에서 이루어지므로 보안이 어떤 식으로든 손상되지 않습니다.
이를 위해 당신이 필요합니다
거의 모든 것이 명확합니다. 내가 명확히 하고 싶은 것은 "MM 수준에서 신호를 보고자 하는 욕구와 후행을 기본 클래스 수준에서 구현해야 하는 이유는 무엇입니까?"입니다.
나는 그것이 나쁠 것이라고 생각합니다(즉, 나쁨). 알고리즘은 일반적이지 않습니다(내 관점에서). 내가 이해하는 한, 당신은 자신의 MM과 후행 모듈을 가지고 있습니다(자신의 알고리즘이 신호에 연결되어 있음).
따라서 해당하는 1.,2.,3을 넣으십시오.
거의 모든 것이 명확합니다. 내가 명확히 하고 싶은 것은 "MM 수준에서 신호를 보고자 하는 욕구와 후행을 기본 클래스 수준에서 구현해야 하는 이유는 무엇입니까?"입니다.
나는 그것이 나쁠 것이라고 생각합니다(즉, 나쁨). 알고리즘은 일반적이지 않습니다(내 관점에서). 내가 이해하는 한, 당신은 자신의 MM과 후행 모듈을 가지고 있습니다(자신의 알고리즘이 신호에 연결되어 있음).
따라서 해당하는 1.,2.,3을 넣으십시오.
사실 마스터는 CExpert 클래스를 기본 클래스로 사용합니다. 따라서 내가 만드는 모듈에서 필요한 기능을 재정의할 수는 없습니다. 신호 모듈 클래스의 인스턴스에 액세스할 수 없기 때문에 처음에는 이 기본 클래스 CEхpert와 이미 호환되지 않습니다.
결국 신호 모듈 클래스의 인스턴스는 Expert.mqh 파일의 CExpert 클래스 필드, 67행에만 저장됩니다.
CExpertSignal *m_signal; // trading signals object그리고 이 필드는 기반으로 생성된 다른 클래스 및 모듈에 대해 공유(접근 불가)되지 않습니다.
바로 이러한 이유로 마스터와 호환되도록 CExpertMoney 및 CExpertTrailing 클래스를 재정의할 수 있는 방법이 없습니다.
결국 부모 클래스에서 액세스가 닫히면 자손은 어떤 식 으로든 액세스를받지 못합니다.
루트를 봐 (c) Kozma Prutkov "격언"
CExpertSignal 클래스의 인스턴스를 전달하지 않고 신호 모듈에서 위치 추적 및 돈 및 위험 관리 모듈로 거래 신호를 전송하는 방법을 알아냈습니다.
CExpertMoney 및 CExpertTrailing 클래스에 두 줄을 추가해 보겠습니다.
ExpertMoney.mqh 파일의 경우:
ExpertTrailing.mqh 파일의 경우:
따라서 우리는 거래 신호를 전송하는 데 필요한 필드와 방법을 결정했습니다. 이제 이러한 거래 신호를 모듈 클래스에 전달해야 합니다. Expert.mqh 파일에서 이 작업을 수행합니다. CExpert 클래스용
거래 신호를 위치 추적 클래스로 전송하기 위해 한 줄을 작성합니다.
각 후행 전에 호출되는 메소드의 맨 처음에 삽입하십시오. CheckTrailingStop():
거래 신호를 자금 및 위험 관리 클래스로 전송하기 위해 한 줄을 작성합니다.
각 위치가 열리기 전에 호출되는 메서드의 맨 처음에 삽입합니다. CheckOpen():
그게 다야, 문제가 해결되었습니다.
이제 m_signaldirection 필드 값을 참조하여 위치 추적 및 자금 및 위험 관리 모듈에서 거래 신호의 현재 값을 얻을 수 있습니다. 이제 CExpertMoney 및 CExpertTrailing 클래스에 새 필드와 메서드가 있다는 문서를 작성하고 변경된 파일을 업데이트에 추가하면 됩니다.
다음은 파일입니다. Expert Advisor의 100행과 123행은 손으로 쓴 것입니다.
더 궁금한 사항이 있으시면 연락주세요.
다음은 파일입니다. Expert Advisor의 100행과 123행은 손으로 쓴 것입니다.
더 궁금한 사항이 있으시면 연락주세요.
젠장, 이 개발자들은 어떤 사람들입니까? 그들은 언제 이미 거래 시스템을 만든 경험이 있는 거래자가 필요로 하는 것에 귀를 기울이고 소스의 수동 개선이 필요하기 때문에 최종 사용자에게 실질적으로 부적합한 거래 시스템을 구축하는 자신의 비전을 발명하지 않을 것입니까? ? 손으로 올라가서 고칠 수 있다는 걸 얼마나 설명할 수 있겠어. 그러고도 프로그래밍에 익숙함에도 불구하고 무엇을, 왜 그런지 알아내려면 오랜 시간이 걸릴 것이다. 그리고 최종 사용자는 코드에 들어갈 가능성이 낮습니다. 그는 프로그래밍을 이해하지 못합니다. 당신 자신이 다음과 같이 선언했습니다.
" 프로그래밍 언어에 대한 지식은 더 이상 거래 로봇을 만들기 위한 전제 조건이 아닙니다. " https://www.mql5.com/ru/articles/240 참조
"이미 MQL5 Wizard의 첫 번째 버전에서는 MQL5 언어의 소스 코드 형태로 간단한 모듈 집합으로 즉시 사용 가능한 Expert Advisor를 빠르게 생성할 수 있었습니다. 이를 위해 MQL5 언어 에 대한 지식이 필요하지도 않았으며 " MQL5 마법사에서 전문가 고문 구축 " 기사를 읽는 것으로 충분했습니다. https://www.mql5.com/ru/articles/275 참조
그리고 이제 프로그래밍 언어에 대한 지식이 필요하다는 것이 밝혀졌습니다. 사용자는 마법사가 작동한 후 코드로 올라가서 무언가를 편집해야 합니다. 저것들. 모든 선언은 이전 선언 - 개발자의 발명 및 속임수입니다.
예를 들어, 다른 모듈 개발자가 작성한 모듈에서 발행한 거래 신호의 수준에 따라 포지션을 열어야 하는 내 자신의 돈 및 위험 관리 모듈을 작성할 것입니다. 결과적으로 내 모듈이 더 이상 마스터와 호환되지 않는 것으로 나타났습니다. 사용자에게 코드의 어딘가로 이동하고 모듈이 작동하기 시작하도록 몇 줄을 삽입해야 한다고 설명하는 방법은 무엇입니까? 결국 모듈 개발자는 모듈을 생성해야 하고 마스터는 모듈이 최소한 서로 충돌하지 않고 서로 완전히 호환되도록 자동으로 하나의 일관된 시스템으로 결합해야 합니다. 그리고 당신은 주인이 이것을하지 않는다는 것을 알게됩니다. 왜냐하면. 그 후에는 코드로 올라가 모든 것을 수동으로 다시 실행해야 합니다.
지난번 메시지에서 지적한 상위 클래스 파일에 6줄만 쓰는 것이 정말 그렇게 어려운 일입니까? 그리고 그 문제는 저절로 해결될 것이고 아무도 소스 코드에 들어가서 무언가를 편집할 필요가 없을 것입니다. 손이 떨어진다고? 마법사 이후에 수동으로 수정하는 방법을 시연하면서 쓰레기에 시간을 낭비하는 이유는 무엇입니까? 나중에 아무도 유사한 문제를 해결하기 위해 코드에 들어가지 않아도 되도록 이 같은 시간을 더 유용한 일에 할애할 수 없습니까?
당신의 회사는 한편으로 완전 자동화를 선언하는 어떤 종류의 이데올로기를 가지고 있으며, 그것에 관해서는 소위 "자동화"후 코드에 들어가서 펜으로 모든 것을 다시 할 것을 제안합니까?
일반적으로 내가 이해하는 한 이 모든 것은 설명할 수 없습니다. 그리고 플랫폼이 조잡하고 자동 거래의 편의를 위해 만들어진 것이 아니라 바로 이 플랫폼의 개발자의 편의를 위해 만들어졌기 때문에 거래자가 MT5로 전환하기를 원하지 않는다는 사실에 놀랄 일이 아닙니다. 그리고 사용자가 프로그래밍을 철저히 배우지 않으면 가능한 한 자동 거래에서 멀어지는 것이 좋습니다.
원하지 않으면 할 필요가 없습니다. 다른 할 일이 없다면 여기 앉아서 각 사용자에게 펜으로 소스 코드를 입력해야 하는 위치와 방법과 정확히 수정해야 할 사항을 설명하십시오.
어쨌든 그런 수준의 논쟁과 허용 가능한 과장의 한계를 넘어 거의 모든 질문을 제거하면 당신과 함께 할 수 없습니다. 실제 작업에는 구두 선동이 아닌 의식적인 의사 결정이 포함됩니다.
나는 당신이 극대주의에 사로잡혀 있거나 단순히 도구의 적용 가능성의 한계를 이해하지 못하는 것 같습니다.
어쨌든 그런 수준의 논쟁과 허용 가능한 과장의 한계를 넘어 거의 모든 질문을 제거하면 당신과 함께 할 수 없습니다. 실제 작업에는 구두 선동이 아닌 의식적인 의사 결정이 포함됩니다.
예, 일반적으로 일자리를 구하지 않았습니다. 돈을 벌기 위해, 자발적으로 협력하는 것에 상당히 만족했습니다. 내가 돈을 버는 방법과 장소는 내가 결정합니다.
글쎄요, 그럴 수도 없고 해서도 안 됩니다. 우리의 일은 제안하는 것이고, 당신의 권리는 거절하는 것입니다. 그들이 말했듯이 : 주인은 주인입니다.
회사가 이미 모든 것을 깨닫고 인형에게 소위 "기성품" Expert Advisors를 만드는 방법을 가르쳤고 마법사를 시연하는 데에만 적합하지만 자동 거래에는 적합하지 않은 경우에도 과거 데이터 주식 곡선이 무섭게 보입니다. 모듈화가 제공되지만 본격적인 거래 시스템을 위한 모듈의 일관성이 없다면 나는 당신을 방해하지 않고 거래 시스템이 어떻게 만들어져야 하고 어떻게 만들어져야 하는지에 대한 당신의 기업 비전을 더 홍보하지 않을 것입니다.
행운을 빕니다!
...
예를 들어, 다른 모듈 개발자가 작성한 모듈에서 발행한 거래 신호의 수준에 따라 포지션을 열어야 하는 내 돈 및 위험 관리 모듈 을 작성할 것입니다. 결과적으로 내 모듈이 더 이상 마스터와 호환되지 않는 것으로 나타났습니다. 사용자에게 코드의 어딘가로 이동하고 모듈이 작동을 시작하도록 몇 줄을 삽입해야 한다고 설명하는 방법은 무엇입니까? 결국 모듈 개발자는 모듈을 생성해야 하고 마스터는 모듈이 최소한 서로 충돌하지 않고 서로 완전히 호환되도록 자동으로 하나의 일관된 시스템으로 결합해야 합니다. 그리고 당신은 주인이 이것을하지 않는다는 것을 알게됩니다. 왜냐하면. 그 후에는 코드로 올라가 모든 것을 수동으로 다시 실행해야 합니다.
지난번 메시지에서 지적한 상위 클래스 파일에 6줄만 작성하는 것이 정말 그렇게 어려운가요? 그리고 그 문제는 저절로 해결될 것이고 아무도 소스 코드에 들어가서 무언가를 편집할 필요가 없을 것입니다. 손이 떨어진다고? 마법사 이후에 수동으로 수정하는 방법을 시연하면서 쓰레기에 시간을 낭비하는 이유는 무엇입니까? 나중에 아무도 유사한 문제를 해결하기 위해 코드에 들어가지 않아도 되도록 이 같은 시간을 더 유용한 일에 할애할 수 없습니까?
...귀하의 접근 방식은 클래스 캡슐화를 깨고 결과적으로 계층적 혼란을 야기합니다.
여가 시간에 Steve McConnell의 책 Perfect Code를 읽으십시오.
간단히 말해 마스터가 장갑을 생산하는 공장이라고 상상해보십시오. 오른손과 왼손에 다섯 손가락 스탬프가 있지만 여섯 손가락 장갑에 대한 작은 주문이 나타납니다. 결국 그런 사람들이 있습니다. 그러나 그들을 위해 우표를 만드는 대신(일괄 처리를 만들고 잠시 동안 거기에 누워 있을 것입니다), 손가락을 움직여서 다섯 손가락 우표를 변경할 것을 제안합니다. 그것은 보편적인 것처럼 보이고 모든 것이 위대하지만 가상의 수백만 개의 다섯 손가락 장갑의 주사위의 힘은 보편성을 위해 약해질 것입니다(작은 필요를 위해 때때로 여섯 손가락 장갑을 풉니 다) . 그런 다음 300 개의 네 손가락 배치에 대한 주문이있을 것이며 잘 입증되고 신뢰할 수있는 템플릿을 다시 무너 뜨릴 것입니다.
당신은 위에서 들었다:
나는 그것이 나쁠 것이라고 생각합니다(즉, 나쁨). 알고리즘은 일반적이지 않습니다(내 관점에서). 내가 이해하는 한, 당신은 자신의 MM과 후행 모듈을 가지고 있습니다(자신의 알고리즘이 신호에 연결되어 있음).
표준 성경을 변경하는 것보다 (상속을 통해) 확장하는 작업을 하는 것이 좋습니다. 그러면 정말 흥미로울 것입니다.
추신 또한 사람들이 복잡한 코드를 다룰 필요가 없도록(위에서 설명한 대로) 완성된 모듈을 bibl로 포장하여 시장에 쏟아낸 다음 Reshetov의 모듈을 연결하고 [전리품 다운로드] 버튼
귀하의 접근 방식은 클래스 캡슐화를 깨고 결과적으로 계층적 혼란을 야기합니다.
여가 시간에 Steve McConnell의 책 Perfect Code를 읽으십시오.
간단히 말해 마스터가 장갑을 생산하는 공장이라고 상상해보십시오. 오른손과 왼손에 다섯 손가락 스탬프가 있지만 여섯 손가락 장갑에 대한 작은 주문이 나타납니다. 결국 그런 사람들이 있습니다. 그러나 그들을 위해 우표를 만드는 대신(일괄 처리를 만들고 잠시 동안 거기에 누워 있을 것입니다), 손가락을 움직여서 다섯 손가락 우표를 변경할 것을 제안합니다. 그것은 보편적인 것처럼 보이고 모든 것이 위대하지만 가상의 수백만 개의 다섯 손가락 장갑의 주사위의 힘은 보편성을 위해 약해질 것입니다(작은 필요를 위해 때때로 여섯 손가락 장갑을 풉니 다) . 그런 다음 300 개의 네 손가락 배치에 대한 주문이 있고 다시 잘 입증되고 안정적인 템플릿이 무너집니다.
당신은 위에서 들었다:
표준 성경을 변경하는 것보다 확장 작업(상속을 통해)하는 것이 좋습니다. 그러면 정말 흥미로울 것입니다.예를 들어, 후행 정지는 모듈의 타사 개발자가 작성한 일부 별도의 신호 시스템에 따라 실행됩니다. 예를 들어 이동 평균 또는 포물선에 따라 신호가 어떤 지점에서 신호 모듈이 출력하는 것과 모순되고 전체 거래 시스템이 불협화음을 일으키기 시작합니다. 돈 및 위험 관리 모듈은 또한 텔레파시로 거래 신호가 약하다는 것을 추측할 수 없으며 열린 위치의 양을 줄여야 할 때이며 신호 모듈과 독립적인 일부 규칙에 따라 행동합니다. 하나는 회전할 때 속도를 줄이도록 요청하고 다른 하나는 가스를 누릅니다. 그리고 소위 마스터의 도움으로 만들어진 전체 거래 시스템은 "백조, 암 및 파이크"라고 불리는 할아버지 Krylov의 우화처럼 밝혀졌습니다. 그 이상도 그 이하도 아닙니다. 그리고 당신의 회사는 자동차 거래를 위해 무모한 고문을 모으는 이 멋진 이데올로기를 강요하려고 합니다. 그리고 우리는 그것을 필요로합니까?
결과적으로 트레이더와 투자자 모두를 놀라게 할 수 있는 자본 및 균형 차트와 함께 거래 시스템을 얻을 수 있습니다( https://www.mql5.com/en/code/833 참조 ).
그러나 이러한 차트의 이유는 모듈 작성자(이 경우 Nikolai Kositsin)가 잘못했기 때문이 아니라 거래 시스템의 다른 모듈이 서로 조정될 수 없고 다르게 작동하기 때문입니다.
그러나 이미 설명하는 것은 무의미합니다. 플랫폼 개발자는 문제를 해결하는 불행한 6줄을 작성하는 대신 포럼에 긴 발판을 작성하고 거래 시스템 개발자가 선동을 퍼뜨리고 캡슐화 원칙을 위반하는 등 치명적인 죄를 지었다고 비난하지만, 자신의 결점과 오해를 바로잡는 손가락.
따라서 더 이상의 논의는 무의미하다. 자신의 의견을 고수하고 원하는 대로 행동하십시오. 나는 이미 피곤하고 아무 소용이 없기 때문입니다. 플랫폼 개발자는 자신이 사용하지 않는 공예품을 뻔뻔하게 이야기하고 자동 거래 플랫폼 사용자가 동일한 공예품을 사용할 수 있는지 여부를 신경 쓰지 않습니다. 개발자는 전혀 신경 쓰지 않습니다. 배고픈 사람은 배고픈 사람을 이해하지 못합니다.
...
Reshetov, 나는 당신의 이 신발류도 감정으로 읽을 수 있습니다. 논쟁하고 싶다면 논쟁하십시오.
마법사의 핵심은 거래자의 대부분의 요구 사항을 충족하는 템플릿을 만드는 것입니다. 웜에는 어드바이저 템플릿이 있으며(직접 작성했습니다), 이는 주요 기능을 설정합니다. 그리고 실제로는 항상 수정되어야 합니다. 그러나 편집은 최소화됩니다. 전혀 편집하지 않도록 템플릿을 만들면 익사할 수 있는 모든 경우에 거대한 코드가 될 것입니다.
마스터는 이미 작동하고 있는 템플릿을 생성하고, 프로그래밍을 전혀 할 줄 모르는 사람도 그대로 사용할 수 있습니다. 코딩을 이해한다면 원하는 방식으로 변경하는 것은 어렵지 않습니다. 표준 성경에서 어떤 것이 어디서 왔으며 모든 것이 어디로 가는지 이해하는 것은 한 번이면 충분합니다. 또한 표준 성경도 샘플로 사용할 수 있으며 원하는 섹션을 코드에 복사하여 붙여넣을 수 있습니다.