Simplifique condicionais complexas sem alterar decisões
Eliminar o aninhamento de condições pode ampliar a elegibilidade acidentalmente. Um cupom que se aplica somente dentro de um ramo premium/de alto valor não deve se tornar uma regra global.
Resumo do laboratório
Ilustração conceitual original (SVG)
| Em resumo | Sua rota |
|---|---|
| Nível e tempo | 300; 55 minutos (estimativa de facilitação) |
| Ação inicial | Escolha linhas que distingam igualdade, sobreposição e comportamento de limite. |
| Materiais do aluno | Baixe 09-conditionals.zip |
| Workspace | Abra a raiz do kit extraído; execute a baseline de . relativa a essa raiz |
| Verificação inicial esperada | O projeto selecionado compila. A compilação sozinha não prova o comportamento. |
| Ajuda de configuração | Baixe, extraia, Git local e GitHub opcional |
[!NOTE] Mover uma condição para fora do pai pode ampliar a elegibilidade.
Conceitos · Primeira tarefa · Lista de evidências · Redefinir
Objetivos de aprendizagem
- Derive uma tabela de decisão antes de reescrever condições.
- Preserve igualdade nos limites, precedência, tetos de desconto e comportamento de erro.
- Escolha predicados nomeados ou cláusulas de guarda com base na semântica.
Antes de começar
Prepare 09-conditionals usando o guia de configuração.
A fixture principal é
ECommercePricingEngine.
A demonstração de aprovação de empréstimos é opcional e puramente fictícia; não é uma política de crédito
nem um sistema para decisões financeiras reais.
Conceitos e casos de uso
| Técnica | Útil quando | Risco |
|---|---|---|
| Predicado nomeado | Uma condição tem um nome significativo no domínio | Esconder condições diferentes sob um único nome |
| Cláusula de guarda | Uma entrada inválida provoca saída antecipada | Pular trabalho obrigatório de auditoria/limpeza |
| Tabela de decisão | As regras se sobrepõem | Presumir que as linhas são mutuamente exclusivas |
| Estratégia por política | Políticas distintas evoluem de forma independente | Adicionar uma hierarquia de classes para ramificações triviais |
Cenário do exercício
PricingEngine.CalculateFinalPrice avalia associação, eventos sazonais, cupons,
frete e tetos específicos por categoria. Preserve as saídas atuais enquanto esclarece
uma família de condições.
Tarefa 1 - Estabeleça a superfície de decisão
-
Leia
ECommercePricingDemo.cseSecurityTest.cs. -
Identifique
User,Coupon,Order,SafeAddDiscounte a lógica específica por categoria. -
Peça um inventário de regras com referências às fontes, ainda não uma proposta de reescrita.
-
Compile e execute:
dotnet build ECommercePricingEngine.csproj -m:1 -p:UseSharedCompilation=false dotnet run --no-build --project ECommercePricingEngine.csproj -
Registre os resultados, incluindo avisos e entradas rejeitadas. Cenários de demonstração e métodos rotulados como de segurança não são um relatório abrangente de segurança ou cobertura.
Tarefa 2 - Derive uma tabela de limites
Comece com estas dimensões e registre o valor esperado real a partir do código-fonte e da linha de base para cada linha selecionada:
| Dimensão | Casos |
|---|---|
| Associação | Guest, Silver, Gold, Premium |
| Pedido de alto valor | Imediatamente abaixo, igual e acima do limite relevante |
| Cupom | Ausente, válido, expirado, tipo inválido, valor excessivo |
| Teto por categoria | Eletrônicos e uma categoria não eletrônica |
| Frete | Nacional, internacional, cupom de frete grátis |
| Pedido inválido | Nulo, vazio, preço negativo, total excessivo |
Não gere o produto cartesiano completo sem avaliar. Escolha casos que diferenciem ramos e interações e explique as lacunas restantes de cobertura.
Tarefa 3 - Planeje uma transformação equivalente
Plan a refactor of membership conditions only. Keep coupon order, category caps,
shipping, and public output unchanged. Show how each selected decision-table row
maps to the new structure. Preserve > versus >= exactly. Do not edit yet.
Revise o comportamento de curto-circuito. Um switch pode melhorar a legibilidade, mas não é evidência
de que regras sobrepostas ou efeitos colaterais foram preservados.
Tarefa 4 - Implemente e valide
- Peça a Agent que implemente o recorte revisado sem alterações de dependências.
- Compare a tabela de decisão com o diff antes de aceitá-lo.
- Transforme as linhas escolhidas em asserções executáveis usando os pontos de entrada atuais do projeto ou um pequeno harness de caracterização.
- Execute novamente a mesma compilação/demonstração e as asserções.
- Altere deliberadamente uma comparação estrita para uma inclusiva; confirme que o caso de igualdade falha e restaure-a.
Verifique seu trabalho
- As linhas da tabela de decisão incluem igualdade e condições sobrepostas.
- Os tetos de desconto e as regras de frete mantêm sua ordem.
- As entradas inválidas mantêm seu comportamento documentado de falha.
- Uma mutação negativa é detectada por uma verificação executável.
- Nenhuma alegação de “menos linhas significa correto” é usada como evidência.
Solução de problemas
Se uma condição sem aninhamento produzir um desconto extra, reconstrua suas condições externas originais. Se o registro em log mudar inesperadamente, inspecione os retornos antecipados. Se apenas os caminhos de sucesso passarem, adicione um caso de falha e um de igualdade antes de continuar a refatoração.
Prática independente
Repita uma extração na cópia opcional de LoanApprovalWorkflow usando somente dados sintéticos. Documente a equivalência das regras sem apresentar a demonstração como um sistema de decisão de crédito justo, legal ou pronto para produção.
Restauração
Salve a tabela de decisão e as saídas e restaure somente os arquivos alterados na sua cópia descartável. Não sobrescreva saídas de referência importadas com resultados fabricados.