여전히 무화과처럼. switch...case를 사용하는 것과 상태 머신 패턴을 사용하는 것은 별개입니다. 위의 글에서와 같이 패턴에서 냄새가 나지 않았다는 것을 텍스트에서 알 수 있습니다.
그러나 당신이 흑백으로 준 기계의 상태에 관한 기사에는 아무것도 쓰여 있지 않습니다.
이제 Vasya가 C#으로 프로젝트를 수행하고 있으며 한 가지 유형의 개체 에 대한 간단한 상태 머신 이 필요하다고 가정해 보겠습니다. 그는 다음과 같이 씁니다.
privateenum State { Disabled, Idle, Animating }
private State state;
void setState(State value ) {
state = value ;
switch (state) {
case State.Disabled:
...
case State.Idle:
...
case State.Animating :
...
break ;
}
}
다음은 다양한 프레임워크와 기성 클래스에 대한 호언장담입니다.
기사의 결론은 이렇습니다.
"그런 다음 Vasya는 이 모든 것에 지쳐 세상에서 가장 단순한 유한 상태 기계 로 돌아갔습니다. 그는 그것을 약간 수정하고 그 안에 코드를 작성하는 방법에 대한 규칙을 생각해 냈습니다."
여전히 무화과처럼. switch...case를 사용하는 것과 상태 머신 패턴을 사용하는 것은 별개입니다. 위의 글에서와 같이 패턴에서 냄새가 나지 않았다는 것을 텍스트에서 알 수 있습니다.
"내가 독창적인 승리 시스템을 발명했습니다..."와 같은 내용을 읽은 다음 마틴의 비뚤어진 프레젠테이션을 읽습니다.
확인. 그렇다면 근본적인 차이점은 무엇입니까?
잘. 증명해야 하는 것입니다. :)
여전히 무화과처럼. switch...case를 사용하는 것과 상태 머신 패턴을 사용하는 것은 별개입니다. 위의 글에서와 같이 패턴에서 냄새가 나지 않았다는 것을 텍스트에서 알 수 있습니다.
그러나 당신이 흑백으로 준 기계의 상태에 관한 기사에는 아무것도 쓰여 있지 않습니다.
이제 Vasya가 C#으로 프로젝트를 수행하고 있으며 한 가지 유형의 개체 에 대한 간단한 상태 머신 이 필요하다고 가정해 보겠습니다. 그는 다음과 같이 씁니다.
다음은 다양한 프레임워크와 기성 클래스에 대한 호언장담입니다.
기사의 결론은 이렇습니다.
"그런 다음 Vasya는 이 모든 것에 지쳐 세상에서 가장 단순한 유한 상태 기계 로 돌아갔습니다. 그는 그것을 약간 수정하고 그 안에 코드를 작성하는 방법에 대한 규칙을 생각해 냈습니다."
첫째, 나는 어떤 기사도 인용하지 않았습니다. :)
둘째, 누군가가 가져와서 허브에 있다는 이유로 기사를 처음으로 진실로 받아들이려면 이것은 조금 ... 음 ...
돌 도끼도 도끼의 일종입니다.
첫째, 나는 어떤 기사도 인용하지 않았습니다. :)
둘째, 누군가가 가져와서 허브에 있다는 이유로 기사를 처음으로 진실로 받아들이려면 이것은 조금 ... 음 ...
돌 도끼도 도끼의 일종입니다.
네, 죄송합니다. Urain이 데려왔습니다.
이 기사에서 상태 패턴을 설명하지 않는다면 실제 상태 패턴은 무엇입니까? 당신이 topo ... 코드를 스튜디오에 가져갈 수 있다면, 우리는 그것에 대해 논의할 것입니다.
중요한 예외: HFT 알고리즘의 논리는 실제로 실행 방법으로 설명됩니다.
거의 동의합니다.
이를 바탕으로 트레이딩 드라이버, 즉 빠른 추세의 상황에서 독립적인 의사 결정을 위한 "두뇌"를 갖추도록 지능화할 계획입니다.
// 트레일 리밋 오더 또는 오픈 바이 마켓?? (실제로 후행 한계를 "음수 영역"으로 이동)
글쎄 ... 나는 구글 과 함께 일할 것이다 .
여기 흥미로운 생각이 있습니다.
거의 동의합니다.
이를 바탕으로 트레이딩 드라이버, 즉 빠른 추세의 상황에서 독립적인 의사 결정을 위한 "두뇌"를 갖추도록 지능화할 계획입니다.
// 트레일 리밋 오더 또는 오픈 바이 마켓?? (실제로 후행 한계를 "음수 영역"으로 이동)