마법사와 전사의 규칙 우회

에서 블로그 게시물이 시리즈 , 에릭 Lippert의이 마법사와 예제로 전사를 사용하여 객체 지향 설계에서 문제를 설명 :

abstract class Weapon { }
sealed class Staff : Weapon { }
sealed class Sword : Weapon { }

abstract class Player 
{ 
  public Weapon Weapon { get; set; }
}
sealed class Wizard : Player { }
sealed class Warrior : Player { }

그런 다음 몇 가지 규칙을 추가합니다.

• 전사는 칼만 사용할 수 있습니다.
• 마법사는 직원 만 사용할 수 있습니다.

그런 다음 C # 유형 시스템을 사용하여 이러한 규칙을 적용하려고하면 (예 : Wizard마법사가 직원 만 사용할 수 있도록 클래스를 책임지게 함) 계속해서 발생하는 문제를 보여줍니다 . Liskov 대체 원칙을 위반하거나 런타임 예외 위험이 발생하거나 확장하기 어려운 코드가 생길 수 있습니다.

그가 생각해 낸 해결책은 Player 클래스가 유효성을 검사하지 않는다는 것입니다. 상태를 추적하는 데만 사용됩니다. 그런 다음 플레이어에게 무기를주는 대신 :

player.Weapon = new Sword();

상태는 Commands에 의해 s에 따라 수정됩니다 Rule.

... 우리 는 두 개의 게임 상태 객체 a 와 a 를 취하는 Command객체 를 만듭니다 . 사용자가 시스템에 "이 마법사는 그 검을 휘 두어야합니다"명령을 발행하면 해당 명령은 일련의 의 컨텍스트에서 평가되어 일련의 s를 생성합니다 . 우리는 하나가 플레이어 시도가 무기를 휘두를 때, 효과가 기존의 무기가 존재하는 경우, 삭제하고 새로운 무기가 플레이어의 무기가되고 있다는 것을 말한다. 첫 번째 규칙을 강화하는 또 다른 규칙이 있는데, 이는 마법사가 검을 휘두를 때 첫 번째 규칙의 효과가 적용되지 않는다는 것입니다.WieldPlayerWeaponRuleEffectRule

저는이 아이디어가 원칙적으로 마음에 들지만 실제로 어떻게 사용되는지에 대해 우려하고 있습니다.

아무것도를 우회하는 개발자를 방지하기 위해 보인다 Commands과 Rule간단하게 설정하여이야 Weapon켜짐 Player. Weapon속성은 액세스 할 수 필요 Wield가 할 수 없도록 명령 private set.

그럼, 수행 이 일에서 개발자를 방지? 그들은 단지 기억하지 않아야합니까?

일련의 블로그 게시물이 이끌어내는 모든 주장은 Part 5에 있습니다 .

우리는 C # 유형 시스템이 Dungeons & Dragons의 규칙을 인코딩하기에 충분한 일반성을 갖도록 설계되었다고 믿을 이유가 없습니다. 왜 우리도 시도하고 있습니까?

우리는“시스템의 규칙을 표현하는 코드는 어디에 있습니까?”라는 문제를 해결했습니다. 게임 상태를 나타내는 개체가 아니라 시스템의 규칙을 나타내는 개체로 들어갑니다. 상태 객체의 관심사는 게임 규칙을 평가하는 것이 아니라 상태를 일관성있게 유지하는 것입니다.

무기, 캐릭터, 몬스터 및 기타 게임 개체는 할 수 있거나 할 수없는 것을 확인할 책임이 없습니다. 규칙 시스템이이를 담당합니다. Command개체 중 하나를 게임 오브젝트에 아무것도되지 않습니다. 그것은 그들과 함께 무언가를 하려는 시도 를 나타냅니다 . 그런 다음 규칙 시스템은 명령이 가능한지 확인하고 규칙 시스템 인 경우 게임 오브젝트에서 적절한 메소드를 호출하여 명령을 실행합니다.

개발자가 첫 번째 규칙 시스템이 허용하지 않는 문자 및 무기로 작업을 수행 하는 두 번째 규칙 시스템 을 만들려는 경우 C #에서는 불쾌한 반사 해킹없이 메소드 호출이 어디 있는지 알 수 없기 때문에 그렇게 할 수 있습니다 에서.

일부 상황 에서 작동 할 수 있는 해결 방법 은 게임 오브젝트 (또는 해당 인터페이스)를 규칙 엔진을 사용하여 하나의 어셈블리에 배치하고 모든 뮤 테이터 메소드를로 표시하는 것 입니다. 게임 오브젝트에 대한 읽기 전용 액세스가 필요한 모든 시스템은 다른 어셈블리에 있으므로 메소드 에만 액세스 할 수 있습니다 . 이것은 여전히 ​​서로의 내부 메소드를 호출하는 게임 오브젝트의 허점을 남깁니다. 그러나 게임 객체 클래스가 멍청한 국가 보유자라는 데 동의했기 때문에 코드 냄새가 분명합니다.internalpublic

원래 코드의 명백한 문제 는 객체 모델링 대신 데이터 모델링을 수행한다는 것입니다 . 링크 된 기사에는 실제 비즈니스 요구 사항에 대한 언급이 전혀 없습니다.

실제 기능 요구 사항을 얻는 것으로 시작합니다. 예 : "모든 플레이어는 다른 플레이어를 공격 할 수 있습니다 ..." 여기:

interface Player {
    void Attack(Player enemy);
}

"플레이어는 공격에 사용되는 무기를 휘두를 수 있고, 마법사는 지팡이를 휘두를 수 있고, 칼을 전사 할 수 있습니다."

public class Wizard: Player {
    ...
    public void Wield(Staff weapon) { ... }
    ...
}
public class Warrior: Player {
    ...
    public void Wield(Sword sword) { ... }
    ...
}

"각 무기는 공격받은 적에게 피해를줍니다." 자, 이제 무기에 대한 공통 인터페이스가 있어야합니다.

interface Weapon {
    void dealDamageTo(Player enemy);
}

등등 ... 왜이없는 Wield()에 Player? 어떤 플레이어도 무기를 휘둘 필요가 없었기 때문입니다.

"어떤 것도 휘 두르 려고 할 수 Player있습니다 ."라는 요구 사항이있을 것 입니다. 그러나 이것은 완전히 다른 것입니다. 아마도 이런 식으로 모델링 할 것입니다.Weapon

interface Player {
    void Attack(Player enemy);
    void TryWielding(Weapon weapon); // Throws UnwieldableException
}

요약 : 요구 사항과 요구 사항 만 모델링하십시오. oo 모델링이 아닌 데이터 모델링을 수행하지 마십시오.

한 가지 방법은 Wield명령을 에 전달하는 것 Player입니다. 플레이어는 다음 실행 Wield명령을하는 검사 적절한 규칙과 반환 Weapon(가), Player다음으로 자신의 무기 필드를 설정합니다. 이런 식으로 무기 필드는 전용 세터를 가질 수 있으며 Wield플레이어 에게 명령을 전달해야만 설정할 수 있습니다 .

개발자가 그렇게하는 것을 막는 것은 없습니다. 실제로 Eric Lippert는 다양한 기술을 시도했지만 모두 약점을 가지고있었습니다. 그 시리즈의 핵심은 개발자가 그렇게하지 못하게하는 것이 쉽지 않았으며 시도한 모든 것에 단점이 있다는 것입니다. 마지막으로 Command규칙이 있는 객체 를 사용하는 것이 좋습니다.

규칙을 사용하면 Weapona의 속성을 a Wizard로 설정할 수 Sword있지만 Wizard, 무기를 휘두르고 공격 하도록 요청하면 아무런 영향을 미치지 않으므로 상태가 변경되지 않습니다. 아래에서 말한 것처럼 :

첫 번째 규칙을 강화하는 또 다른 규칙이 있는데, 이는 마법사가 검을 휘두를 때 첫 번째 규칙의 효과가 적용되지 않는다는 것입니다. 그 상황에 대한 효과는“슬픈 트롬본 소리를 내고, 사용자는 이번 차례에 대한 행동을 잃고, 게임 상태는 변경되지 않습니다.

다시 말해서, 우리는 type그가 여러 가지 다른 방법을 시도했지만 그것을 좋아하지 않았거나 작동하지 않는 관계를 통해 그러한 규칙을 시행 할 수 없습니다 . 따라서 그가 할 수있는 유일한 일은 런타임에 무언가를하는 것입니다. 그가 예외를 고려하지 않기 때문에 예외를 던지는 것은 좋지 않았다.

그는 마침내 위의 해결책을 선택했습니다. 이 솔루션은 기본적으로 모든 무기를 설정할 수 있다고 말하지만 무기를 생산할 때 올바른 무기가 아니라면 본질적으로 쓸모가 없습니다. 그러나 예외는 발생하지 않습니다.

좋은 해결책이라고 생각합니다. 어떤 경우에는 try-set 패턴도 사용합니다.

저자의 첫 번째 폐기 솔루션은 유형 시스템별로 규칙을 나타내는 것이 었습니다. 형식 시스템은 컴파일 타임에 평가됩니다. 유형 시스템에서 규칙을 분리하면 더 이상 컴파일러에서 검사하지 않으므로 개발자가 실수를 저지르는 것을 막을 수있는 것은 없습니다.

그러나이 문제는 컴파일러가 확인하지 않는 모든 로직 / 모델링이 직면하며 이에 대한 일반적인 대답은 (단위) 테스트입니다. 따라서 저자가 제안한 솔루션에는 개발자의 오류를 피하기 위해 강력한 테스트 장치가 필요합니다. 런타임시에만 감지되는 오류에 대해 강력한 테스트 하네스가 필요한 시점을 강조하려면 동적 언어에서 강력한 테스트를 위해 강력한 타이핑을 교환해야한다는 Bruce Eckel 의이 기사를 참조하십시오.

결론적으로 개발자가 실수를 저 지르지 못하게 할 수있는 유일한 방법은 모든 규칙이 준수되는지 확인하는 일련의 (단위) 테스트를하는 것입니다.

여기서 미묘한 부분을 놓쳤을 수도 있지만 문제가 형식 시스템에 있는지 확실하지 않습니다. 어쩌면 C #에서 규칙이있을 수 있습니다.

예를 들어에서 Weaponsetter를 보호 하여이 유형을 완전히 안전하게 만들 수 있습니다 Player. 그런 다음 추가 setSword(Sword)와 setStaff(Staff)에 Warrior와 Wizard그 전화 보호 세터 각각.

이렇게하면 Player/ Weapon관계가 정적으로 검사되며 신경 쓰지 않는 코드는 a Player를 사용 하여을 얻을 수 있습니다 Weapon.

그렇다면 개발자가 이것을 방해하는 것은 무엇입니까? 그들은 단지 기억하지 않아야합니까?

이 질문은 " 검증을 어디에 두어야합니까?"(대부분 ddd도 주목할 것) 라는 매우 거룩한 주제와 사실상 동일 합니다.

따라서이 질문에 대답하기 전에 스스로에게 묻어 야합니다. 따라야 할 규칙의 성격은 무엇입니까? 그들은 돌로 새겨지고 실체를 정의합니까? 이러한 규칙을 어기면 실체가 중지 되는가? 그렇다면 이러한 규칙을 명령 유효성 검사 로 유지하면서 엔티티에도 넣으십시오. 따라서 개발자가 명령 유효성 검사를 잊어 버린 경우 엔티티는 유효하지 않은 상태가 아닙니다.

그렇지 않은 경우 본질적으로이 규칙은 명령에 따라 다르며 도메인 엔터티에 상주해서는 안됩니다. 따라서이 규칙을 위반하면 수행 할 수 없었지만 잘못된 모델 상태가 아닌 작업이 수행됩니다.