그런 다음, 우리는 그 기사에 나오는 설명이 없는 태블릿 하나를 아주, 아주 꿰뚫어 생각하면서 그것이 무엇을 의미할 수 있는지 생각합니다.
다 읽은 후에도 "와! 상태 프로그래밍이 정말 멋지네요!"와 같은 내용이 남아 있다면 - 글쎄, 그렇게 생각해.
나 자신을 대신하여 State 프로그래밍의 주요 문제는 쓸모없는 모드를 많이 생성하는 상황이라는 점을 추가하겠습니다(N State 열 참조). 상태 프로그래밍에서 각 모드는 해당 규칙을 별도로 설명해야 합니다. 예를 들어 설명하겠습니다. 구매 모드에 있다고 가정해 보겠습니다. 로봇이 다른 위치를 열기로 결정할 때까지는 모든 것이 정상입니다. 그리고 정말, 왜 안되지? 기존 포지션을 종료하기 위한 조건이 충족되지 않고, 청산하기에는 너무 이르며, 새로운 신호를 놓칠 수 없습니다. 그리고 이것이 문제가 시작되는 곳입니다. 새 신호가 도착하는 순간 로봇은 구매 모드에 있고 새 위치를 여는 규칙은 상태 모드(새 입력 신호를 기다리고 검색)에 있기 때문입니다. 이제 매수 모드에서 상태 모드에서와 동일한 포지션 개설 규칙을 다시 설명해야 합니다. 그리고 만약 새로운 위치가 반대 방향(헤지)이라면? 그런 입장이 열리면 앞으로 어떻게 해야 할까요? 결국, 유지 관리 로직은 Sell 모드에서 설명되고 로봇은 Buy 모드에 있습니다. 그냥 매도 모드로 전환할 수 있지만 나머지 매수 포지션은 어떻게 해야 합니까? 일반적으로 이 경우 BuyAndSell과 같은 다른 쓸모없는 모드를 작성해야 합니다. 모드가 중복되면 다른 상황이 발생합니다. 동일한 작업이 코드의 다른 부분에서 수행됩니다. 일반적으로 지수 치질을 좋아하는 사람들에게는 상태 프로그래밍이 가장 중요합니다.
Vladix : 이제 그들은 포함을 위해 상속을 포기하려고합니다. 다중 상속에 대한 태도가 어떠해야 하는지 상상할 수 있습니까?
다중 상속 없이는 인터페이스 수준에서 수평 링크를 구성하는 것이 불가능합니다. 패러다임은 간단합니다. 모든 개체가 인터페이스를 원하는 수만큼 지원할 수 있습니다. 다중 상속은 그 자체로 확실히 나쁜 것입니다. C#에서는 이유 없이 금지되지만 반대로 인터페이스 사용은 권장됩니다.
저는 State 프로그래밍에 직접적으로 익숙하며 몇 년 동안 직접 사용해 왔습니다. 하지만 이 방법을 한동안 사용하다가 포기하고 이를 기반으로 더 투명하고 간단하며 더 적합한 거래 모델을 개발하기로 결정했습니다.
우리는 이 기사를 주의 깊게 읽었습니다. 자동 거래 시스템을 만드는 새로운 방법으로서의 자동화 프로그래밍
그런 다음 그녀에게 이 설명 을 주의 깊게 읽어 주십시오.
그런 다음, 우리는 그 기사에 나오는 설명이 없는 태블릿 하나를 아주, 아주 꿰뚫어 생각하면서 그것이 무엇을 의미할 수 있는지 생각합니다.
다 읽은 후에도 "와! 상태 프로그래밍이 정말 멋지네요!"와 같은 내용이 남아 있다면 - 글쎄, 그렇게 생각해.
나 자신을 대신하여 State 프로그래밍의 주요 문제는 쓸모없는 모드를 많이 생성하는 상황이라는 점을 추가하겠습니다(N State 열 참조). 상태 프로그래밍에서 각 모드는 해당 규칙을 별도로 설명해야 합니다. 예를 들어 설명하겠습니다. 구매 모드에 있다고 가정해 보겠습니다. 로봇이 다른 위치를 열기로 결정할 때까지는 모든 것이 정상입니다. 그리고 정말, 왜 안되지? 기존 포지션을 종료하기 위한 조건이 충족되지 않고, 청산하기에는 너무 이르며, 새로운 신호를 놓칠 수 없습니다. 그리고 이것이 문제가 시작되는 곳입니다. 새 신호가 도착하는 순간 로봇은 구매 모드에 있고 새 위치를 여는 규칙은 상태 모드(새 입력 신호를 기다리고 검색)에 있기 때문입니다. 이제 매수 모드에서 상태 모드에서와 동일한 포지션 개설 규칙을 다시 설명해야 합니다. 그리고 만약 새로운 위치가 반대 방향(헤지)이라면? 그런 입장이 열리면 앞으로 어떻게 해야 할까요? 결국, 유지 관리 로직은 Sell 모드에서 설명되고 로봇은 Buy 모드에 있습니다. 그냥 매도 모드로 전환할 수 있지만 나머지 매수 포지션은 어떻게 해야 합니까? 일반적으로 이 경우 BuyAndSell과 같은 다른 쓸모없는 모드를 작성해야 합니다. 모드가 중복되면 다른 상황이 발생합니다. 동일한 작업이 코드의 다른 부분에서 수행됩니다. 일반적으로 지수 치질을 좋아하는 사람들에게는 상태 프로그래밍이 가장 중요합니다.
"여기는 Mikhalych와 같습니다"(c) ... 그리고 이것을 투명하게 암시하고 있습니다.
(fcplm)
예, 아무 것도 없습니다.
여기서 저는 MQL5가 다중 상속을 지원하고 클래스가 추상 메소드를 선언할 수 있다면 인터페이스를 사용할 수 있는 길이 열릴 것이라고 생각했습니다. 이는 대규모 프로젝트에 매우 유용할 것입니다.
추상적인 방법은 명시적으로 금지되어 있지 않습니다(저는 종종 대체 표기법을 사용합니다).
그리고 다중 상속은 큰 장점이 될 것입니다.
추상 메서드는 직접 금지되지 않으며 다중 상속은 큰 장점이 될 것입니다.
Rosh의 말을 인용하자면, 이것이 나무를 자르는 데 어떻게 도움이 됩니까?
자주 묻는 질문 4에 앉아서 wus로 날려 버리지 않으며 추상 메서드 및 다중 상속에 대해 쉬지 않습니다.
추상적인 방법이 있기는 하지만 적어도 그렇지는 않지만 여전히 프로젝트를 구조화하는 작업을 제거하지는 않습니다.
그건 그렇고, 동일한 작업을 구현하기 위한 옵션이 많을수록 적용할 옵션을 선택하기가 더 어렵습니다.
프로그래머는 종종 코드 아름다움의 작업에 빠지는 것으로 나타났습니다. 이것은 예술을 위한 예술입니다.
추신과 일반적으로 (내 자신을 위해 말하면서) 나는 프로젝트 구축 (계획)의 우표가 많을수록 더 쉽다는 것을 알았습니다.
그런 다음 변경할 수 있습니다, 다시 변경, 다시 변경, 다시 변경,
그러나 초기 프레임(그렇게 뜨겁지는 않지만)은 전체 구성의 톤을 설정합니다.
Rosh의 말을 인용하자면, 이것이 나무를 자르는 데 어떻게 도움이 됩니까?
그런 다음 변경할 수 있습니다, 다시 변경, 다시 변경, 다시 변경,
그러나 초기 프레임(그렇게 뜨겁지는 않지만)은 전체 구성의 톤을 설정합니다.
장작을 자르는 속도가 빨라집니다.
어떻게 그리고 어떻게 생겼는지에 대한 명확한 아이디어가 이미 있다면 마음에 따라 MQL4에서 모든 것을 할 수 있습니다.
그리고 그러한 표현이 없다면 많은 변경과 추가가 있을 것입니다. 특히 다중 상속을 사용하면 최소한의 오버헤드로 변경할 수 있습니다.
나는 추상적인 방법에 동의합니다. 단지 아름다운 형태의 글쓰기일 뿐입니다.
장작을 자르는 속도가 빨라집니다.
어떻게 그리고 어떻게 생겼는지에 대한 명확한 아이디어가 이미 있다면 마음에 따라 MQL4에서 모든 것을 할 수 있습니다.
그리고 그러한 표현이 없다면 많은 변경과 추가가 있을 것입니다. 특히 다중 상속을 사용하면 최소한의 오버헤드로 변경할 수 있습니다.
이제 그들은 포함을 위해 상속을 포기하려고합니다. 다중 상속에 대한 태도가 어떠해야 하는지 상상할 수 있습니까?
FAQ :
예, 아무 것도 없습니다.
여전히 무화과처럼. switch...case를 사용하는 것과 상태 머신 패턴을 사용하는 것은 별개입니다. 위의 글에서와 같이 패턴에서 냄새가 나지 않았다는 것을 텍스트에서 알 수 있습니다.
"내가 독창적인 승리 시스템을 발명했습니다..."와 같은 내용을 읽은 다음 마틴의 비뚤어진 프레젠테이션을 읽습니다.