Contornando as regras em magos e guerreiros

Em esta série de posts , Eric Lippert descreve um problema no design orientado a objetos usando assistentes e guerreiros como exemplos, em que:

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 { }

e depois adiciona algumas regras:

• Um guerreiro só pode usar uma espada.
• Um assistente pode usar apenas uma equipe.

Ele então demonstra os problemas com os quais você se depara se tentar aplicar essas regras usando o sistema do tipo C # (por exemplo, responsabilizando a Wizardclasse por garantir que um assistente possa usar apenas uma equipe). Você viola o princípio de substituição de Liskov, corre o risco de exceções em tempo de execução ou acaba com um código difícil de estender.

A solução que ele apresenta é que nenhuma validação é feita pela classe Player. É usado apenas para rastrear o estado. Então, em vez de dar uma arma a um jogador:

player.Weapon = new Sword();

o estado é modificado por se de Commandacordo com Rules:

... criamos um Commandobjeto chamado Wieldque leva dois objetos de estado do jogo, a Playere a Weapon. Quando o usuário emite um comando para o sistema “esse assistente deve usar essa espada”, esse comando é avaliado no contexto de um conjunto de Rules, que produz uma sequência de Effects. Temos uma Ruleque diz que quando um jogador tenta empunhar uma arma, o efeito é que a arma existente, se houver, é descartada e a nova arma se torna a arma do jogador. Temos outra regra que fortalece a primeira regra, que diz que os efeitos da primeira regra não se aplicam quando um mago tenta empunhar uma espada.

Eu gosto dessa idéia em princípio, mas tenho uma preocupação sobre como ela pode ser usada na prática.

Nada parece impedir que um desenvolvedor de iludirem o Commandse Ruleé simplesmente definindo o Weaponem um Player. A Weaponpropriedade precisa estar acessível pelo Wieldcomando, portanto, não pode ser feita private set.

Então, o que impede um desenvolvedor de fazer isso? Eles apenas precisam se lembrar de não?

Todo o argumento que uma série de postagens do blog leva até a Parte Cinco :

Não temos motivos para acreditar que o sistema do tipo C # foi projetado para ter generalidade suficiente para codificar as regras de Dungeons & Dragons, então por que estamos tentando?

Resolvemos o problema de “para onde vai o código que expressa as regras do sistema?” Ele entra em objetos que representam as regras do sistema, não nos objetos que representam o estado do jogo; a preocupação dos objetos estatais é manter seu estado consistente, não na avaliação das regras do jogo.

Armas, personagens, monstros e outros objetos do jogo não são responsáveis ​​por verificar o que podem ou não fazer. O sistema de regras é responsável por isso. O Commandobjeto também não está fazendo nada com os objetos do jogo. Representa apenas a tentativa de fazer algo com eles. O sistema de regras verifica se o comando é possível e quando é o sistema de regras executa o comando chamando os métodos apropriados nos objetos do jogo.

Se um desenvolvedor quiser criar um segundo sistema de regras que faça coisas com personagens e armas que o primeiro sistema de regras não permitiria, ele poderá fazer isso porque em C # você não pode (sem hacks de reflexão desagradáveis) descobrir de onde vem uma chamada de método de.

Uma solução alternativa que pode funcionar em algumas situações é colocar os objetos do jogo (ou suas interfaces) em um assembly com o mecanismo de regras e marcar como mutador qualquer método internal. Todos os sistemas que precisam de acesso somente leitura aos objetos do jogo estariam em uma montagem diferente, o que significa que eles só poderiam acessar os publicmétodos. Isso ainda deixa a brecha dos objetos do jogo que chamam os métodos internos um do outro. Mas fazer isso seria um cheiro óbvio para o código, porque você concordou que as classes de objetos do jogo deveriam ser detentoras de estado.

O problema óbvio do código original é que ele está fazendo Modelagem de Dados em vez de Modelagem de Objetos . Observe que não há absolutamente nenhuma menção aos requisitos comerciais reais no artigo vinculado!

Eu começaria tentando obter requisitos funcionais reais. Por exemplo: "Qualquer jogador pode atacar outros jogadores, ...". Aqui:

interface Player {
    void Attack(Player enemy);
}

"Os jogadores podem empunhar uma arma usada no ataque, os Magos podem empunhar um Cajado, os Guerreiros uma Espada":

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

"Cada arma causa dano ao inimigo atacado". Ok, agora temos que ter uma interface comum para a Arma:

interface Weapon {
    void dealDamageTo(Player enemy);
}

E assim por diante ... Por que não há Wield()no Player? Porque não havia exigência de que qualquer jogador pudesse usar qualquer arma.

Posso imaginar que haveria um requisito que diz: "Qualquer um Playerpode tentar exercer algum Weapon". Isso seria uma coisa completamente diferente no entanto. Eu modelaria talvez dessa maneira:

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

Resumo: Modele os requisitos e apenas os requisitos. Não faça modelagem de dados, isso não é modelagem oo.

Uma maneira seria passar o Wieldcomando para o Player. O jogador então executa o Wieldcomando, que verifica as regras apropriadas e retorna o Weapon, com o qual Playerele define seu próprio campo de arma. Dessa forma, o campo Arma pode ter um setter privado e só pode ser definido através da passagem de um Wieldcomando para o jogador.

Nada impede que o desenvolvedor faça isso. Na verdade, Eric Lippert tentou muitas técnicas diferentes, mas todas tinham fraquezas. Esse era o ponto principal da série que impedir o desenvolvedor de fazer isso não é fácil e tudo o que ele tentou teve desvantagens. Finalmente, ele decidiu que usar um Commandobjeto com regras é o caminho a seguir.

Com as regras, você pode definir a Weaponpropriedade de Wizarda como a, Swordmas quando você pede Wizardpara usar a arma (espada) e atacar, ela não terá nenhum efeito e, portanto, não mudará nenhum estado. Como ele diz abaixo:

Temos outra regra que fortalece a primeira regra, que diz que os efeitos da primeira regra não se aplicam quando um mago tenta empunhar uma espada. Os efeitos para essa situação são "fazer um som trombone triste, o usuário perde sua ação neste turno, nenhum estado do jogo é alterado.

Em outras palavras, não podemos impor essa regra por meio de typerelacionamentos que ele tentou de muitas maneiras diferentes, mas que não gostaram ou não deram certo. Portanto, a única coisa que ele disse que podemos fazer é fazer algo sobre isso em tempo de execução. Lançar uma exceção não era bom porque ele não a considera uma exceção.

Ele finalmente escolheu a solução acima. Essa solução basicamente diz que você pode definir qualquer arma, mas quando você a produz, se não a arma certa, seria essencialmente inútil. Mas nenhuma exceção seria lançada.

Eu acho que é uma boa solução. Embora, em alguns casos, eu também siga o padrão de teste.

A primeira solução descartada do autor foi representar as regras pelo sistema de tipos. O sistema de tipos é avaliado em tempo de compilação. Se você desanexar as regras do sistema de tipos, elas não serão mais verificadas pelo compilador; portanto, não há nada que impeça um desenvolvedor de cometer um erro per se.

Mas esse problema é enfrentado por toda peça de lógica / modelagem que não é verificada pelo compilador e a resposta geral para isso é o teste (de unidade). Portanto, a solução proposta pelo autor precisa de um forte recurso de teste para contornar os erros dos desenvolvedores. Para enfatizar esse ponto de precisar de um forte recurso de teste para erros que só são detectados em tempo de execução, consulte este artigo de Bruce Eckel, que argumenta que você precisa trocar a digitação forte por testes mais fortes em linguagens dinâmicas.

Em conclusão, a única coisa que pode impedir os desenvolvedores de cometer erros é ter um conjunto de testes (unitários), verificando se todas as regras são respeitadas.

Talvez eu tenha perdido uma sutileza aqui, mas não tenho certeza se o problema está no sistema de tipos. Talvez seja com convenção em c #.

Por exemplo, você pode tornar esse tipo completamente seguro, protegendo o Weaponsetter Player. Em seguida, adicione setSword(Sword)e setStaff(Staff)para Warriore, Wizardrespectivamente, que chamam o setter protegido.

Dessa forma, o relacionamento Player/ Weaponé estaticamente verificado e o código que não se importa pode usar apenas a Playerpara obter a Weapon.

Então, o que impede um desenvolvedor de fazer isso? Eles apenas precisam se lembrar de não?

Essa questão é efetivamente a mesma com o tópico bastante conhecido como " onde colocar a validação " (provavelmente observando também o ddd).

Portanto, antes de responder a essa pergunta, deve-se perguntar: qual é a natureza das regras que você deseja seguir? Eles são esculpidos em pedra e definem a entidade? A quebra dessas regras resulta em uma entidade que deixa de ser o que é? Se sim, além de manter essas regras na validação de comandos , coloque-as em uma entidade também. Portanto, se um desenvolvedor esquecer de validar o comando, suas entidades não estarão em um estado inválido.

Se não - bem, isso implica inerentemente que essas regras são específicas de comandos e não devem residir em entidades de domínio. Portanto, violar essas regras resulta em ações que não deveriam ter sido permitidas, mas não no estado de modelo inválido.