RobotLegs 도메인 로직 - 배치 위치

Question

Robotlegs에서 도메인 로직이 명령 (컨트롤러) 또는 모델에 있어야합니까?

예 : 나는 "Tic Tac Toe"게임을 만들고 있다고 말할 수 있습니다. 내가 가진 : GameMadiatore, CellSelectedCommand, BoardModel.

사용자가 셀을 클릭하면 "GameMadiatore"가 "CellSelectedCommand"를 시작하는 이벤트를 시작합니다. "3 행 연속 찾기"논리가 "BoardModel"또는 "CellSelectedCommand"또는 다른 명령에 있어야합니까?

Answer 1

원자 명령을 작성하는 것이 좋습니다.

이것은 명령이 1 가지만하고 1 가지만 수행해야 함을 의미합니다. 이렇게하면 나중에 리팩토링하지 않고도 응용 프로그램 논리를 쉽게 다시 배선 할 수 있습니다.

위의 경우 사용자의 생각이 정확하지만 다른 명령은 올바르게 수행됩니다. 예를 들어 :

• CellSelectedCommand
• Check3InRowCommand
• StartNewGameCommand
• PlayerWinsCommand
• .. MVCS에 대한

좀 더 원칙 :

• 중재자 : 우편 배달부로 간주되어야합니다. 그것은 당신의 견해와 당신의 신청 사이에 중개자 역할을 할 것입니다. 원한다면 ViewController라고 부르 자.하지만 조금 더 초보적이다.
• 명령 : 컨트롤러 논리로 간주 할 수 있습니다. 모든 의사 결정은 여기에서 수행 할 수 있습니다. 여기에서 모델을 업데이트하십시오.
• 모델 : 응용 프로그램 상태 만 반영해야합니다. 예를 들어 게임이 승리했는지 여부를 나타내는 부울입니다.

건배

Answer 2

@DennisJaamann 말했듯이 - 명령이 하나의 일을해야한다. 그러나 도에는 실제 도메인 논리가 포함되어서는 안됩니다. 또한 모델이나 View 클래스에 있어야하지 않습니다.

다음과 같은 이유가 있습니다. 게임 로직을 프레임 워크 특정 클래스에 넣는다면 게임을이 특정 프레임 워크에 묶을 수 있습니다 (좋은 게임이라 할지라도). 그러나 TicTacToe의 게임 규칙은 RobotLegs, PureMVC 또는 다른 기술 선택에 관계없이 항상 동일하게 유지되어야합니다. 예를 들어, 몇 달 만에 새로운 멋진 모바일 장치 용 게임 버전을 만들기로 결정하고 공급 업체별 MVC 프레임 워크 및 구성 요소를 사용하려면 처음부터 모든 것을 다시해야합니다. 또한 게임 논리를 몇 가지 명령 클래스에 분산 시키면 코드를 읽고, 이해하는 것이 훨씬 더 어려워집니다. 이렇게하면 디버깅이 정말 어려워집니다.

As Uncle Bob Martin would put it : 프레임 워크는 배달 메커니즘입니다. 그 이상도 이하도 아닌. 정보를 제공하는 데 사용해야합니다 (예 :그것을 사용자에게 제시하고, 사용자 상호 작용 이벤트를 처리합니다. 그러나 실제 도메인 논리는 의존성을 거꾸로하는 프레임 워크에 종속되지 않는 유스 케이스 클래스에 있어야하며 따라서 전달 메커니즘과 완전히 분리됩니다.

그래서 게임 인터페이스를 만들고, ITicTacToe이라고하고 게임 클래스 인 TicTacToe에 구현합니다. 여기에는 상태 (즉, 이미 표시된 셀)와 로직 (즉, 3 회 연속) TicTacToe의 단일 라운드를 수행하고 모니터링합니다. 이러한 것들은 같은 목적을 위해 사용되기 때문에 함께 있습니다. single reason to change : TicTacToe의 규칙이 변경되는 경우에만!

TDD를 사용하여 게임의 동작을 구현하고 점수 등을 추적하는 대신 게임이 승리하거나 분실 될 때마다 게임 클래스를 파견하도록하십시오. 이것은 응용 프로그램 로직 주위에 게임인데이지만 게임 그 자체가 아닙니다.

다음 게임을 CellSelectedCommand에 삽입하고 게임 클래스에서 해당 메소드를 호출하고 로컬 게임 이벤트를 청취 한 다음 중앙 디스패처를 통해 응용 프로그램 전체 이벤트를 전달할 수 있습니다. 이것들을 사용하여 별도의 과 GameLostCommand 클래스를 트리거하여 점수에 점수를 추가하고 ScoreModel에 보유 할 수 있습니다. 모델에는 공유 상태 (즉, 하나 이상의 작업에서 필요로하는 데이터) 만 포함되어야합니다. 서랍과 상자 같은 모델을 큰 선반에 올려 놓고 생각합니다. 작업을 수행하기 위해 필요한 일부 데이터 (예 : 게임을 시작하기 전에 일부 사용자 정보)를 처리하고 처리 한 다음 나중에 저장합니다 (점수 저장). 핵심 응용 프로그램 로직을 프레임 워크 및 전달 메커니즘에 항상 유지하려고 시도하십시오. - 시스템의 중심이 아닌 확장 기능, 플러그인이어야합니다. .