[Pt. 2] Melhorando sua lógica com Specification Pattern

Introdução

Estamos desenvolvendo uma aplicação para verificar os sintomas da COVID-19 dos pacientes, e designá-los para a área correta através do Specification Pattern

Este post contem duas partes:

• [Pt. 1] Melhorando sua lógica com Specification Pattern
• [Pt. 2] Melhorando sua lógica com Specification Pattern

As regras básicas de negócio ja foram atendidas, e ao final do primeira parte, ficamos com a seguinte estrutura de pastas e arquivos.

# Estrutura inicial de pastas
├── src
│   ├── patient
|   │   ├── patient.entity.ts
|   │   ├── symptoms.enum.ts
|   │   ├── patient.specification.ts
│   ├── specification
|   │   ├── specification.class.ts
|   │   ├── specification.interface.ts
├── package.json
├── pnpm-lock.yaml
└── .gitignore

Continuando...

Para continuarmos, precisar compor as regras existentes para criar as regras mais complexas. Que são estas:

• O paciente precisa de UTI

  • O Paciente deve possuir todos os sintomas comuns
  • O Paciente deve possuir pelo menos um sintoma crítico

• O paciente precisa de avaliação médica

  • O Paciente deve possuir todos os sintomas comuns
  • O Paciente deve possuir todos os sintomas menos comuns
  • O Paciente deve possuir pelo menos um sintoma crítico

Para que isso seja possível, precisamos aprimorar a classe de Specification e a interface de ISpecification para que aceite o método and e or.

Adicione o método abstrato para a especificação and e or, que receba uma propriedade ISpecification

/* src/specification/specification.interface.ts */

export abstract class ISpecification<T> {
  abstract isSatisfiedBy(target: T): boolean;
  abstract and(other: ISpecification<T>): ISpecification<T>;
  abstract or(other: ISpecification<T>): ISpecification<T>;
}

Adicione e implemente o método recém criado, ficará assim:

/* src/specification/specification.class.ts */

export abstract class Specification<T> implements ISpecification<T> {
  abstract isSatisfiedBy(target: T): boolean;

  and(other: ISpecification<T>): ISpecification<T> {
    return new AndSpecification<T>(this, other);
  }
  or(other: ISpecification<T>): ISpecification<T> {
    return new OrSpecification<T>(this, other);
  }
}

Vamos agora criar as classes que implementam AndSpecification e OrSpecification, para disponibiliza-los globalmente para as classes que estendem Specification.

Você pode usar como base a Tabela da Verdade (Table of Truth) para criar outras lógicas de comparação.

Implementação das classes

AndSpecification

/* src/specification/specification.class.ts */

export class AndSpecification<T> extends Specification<T> {
  constructor(private readonly one: ISpecification<T>, private readonly other: ISpecification<T>) {
    super();
  }

  isSatisfiedBy(target: T): boolean {
    return this.one.isSatisfiedBy(target) && this.other.isSatisfiedBy(target);
  }
}

export class AndSpecification<T> extends Specification<T>

constructor(
    private readonly one: ISpecification<T>,
    private readonly other: ISpecification<T>
) {
  super();
}

isSatisfiedBy(target: T): boolean {
  return this.one.isSatisfiedBy(target) && this.other.isSatisfiedBy(target);
}

OrSpecification

/* src/specification/specification.class.ts */

export class OrSpecification<T> extends Specification<T> {
  constructor(private readonly one: ISpecification<T>, private readonly other: ISpecification<T>) {
    super();
  }

  isSatisfiedBy(target: T): boolean {
    return this.one.isSatisfiedBy(target) || this.other.isSatisfiedBy(target);
  }
}

export class OrSpecification<T> extends Specification<T>

constructor(
    private readonly one: ISpecification<T>,
    private readonly other: ISpecification<T>
) {
  super();
}

isSatisfiedBy(target: T): boolean {
  return this.one.isSatisfiedBy(target) || this.other.isSatisfiedBy(target);
}

Regras de negócio compostas

Com as especificações de lógicas criadas, podemos criar as duas lógicas restantes.

• Paciente precisa de UTI
• Paciente precisa de avaliação médica

Paciente precisa de UTI

Para que essa regra de atendida, precisamos que outras regras sejam atendidas. Que são:

• O paciente deve possuir todos os sintomas comuns
  • Regra criado em: HasAllCommonSymptomsSpecification
• O Paciente deve possuir pelo menos um sintoma crítico
  • Regra criado em: HasSomeSeriousSymptomsSpecification

Agora, vamos criar uma classe chamada NeedsUTI, e aplicar a lógica AND. Seu código ficará dessa forma.

/* src/patient/patient.specification.ts */

export class NeedsUTI extends Specification<Patient> {
  isSatisfiedBy(patient: Patient): boolean {
    return new HasAllCommonSymptomsSpecification()
      .and(new HasSomeSeriousSymptomsSpecification())
      .isSatisfiedBy(patient);
  }
}

Note que estamos seguinte do as regras de negócio estabelecidas na aplicação.

O Paciente deve conter todos os sintomas comuns e pelo menos um sintoma crítico para ir para a UTI.

Paciente precisa de atendimento médico

Para que essa regra de atendida, precisamos que outras regras sejam atendidas. Que são:

• O paciente deve possuir todos os sintomas comuns;
  • Regra criado em: HasAllCommonSymptomsSpecification
• O Paciente deve possuir pelo menos um sintoma crítico;
  • Regra criado em: HasSomeSeriousSymptomsSpecification
• O Paciente deve possuir pelo menos um sintoma menos comum;
  • Regra criado em: HasSomeLessSymptomsSpecification

Agora, vamos criar uma classe chamada NeedMedical, e aplicar a lógica OR. Seu código ficará dessa forma.

/* src/patient/patient.specification.ts */

export class NeedMedical extends Specification<Patient> {
  isSatisfiedBy(patient: Patient): boolean {
    return new HasAllCommonSymptomsSpecification()
      .or(new HasSomeSeriousSymptomsSpecification())
      .or(new HasSomeLessSymptomsSpecification())
      .isSatisfiedBy(patient);
  }
}

O Paciente deve conter todos os sintomas comuns ou pelo menos um sintoma crítico ou pelo menos um sintoma menos comum para ir para o atendimento médico.

const patient = new Patient({
  name: "Jhon Doe",
  symptoms: ["PERDA_DE_FALA"],
});

const patientNeedMedical = new NeedMedical().isSatisfiedBy(patient);

if (patientNeedMedical) {
  // Sua lógica
}

Agora a com a base e a lógica entendidas, podemos criar qualquer lógica para atender uma regra de negócio.
Por exemplo:

O Paciente deve possuir sintomas comuns e um sintoma menos comum e não possuir nenhum sintomas críticos

/* src/patient/patient.specification.ts */

export class LessUrgent extends Specification<Patient> {
  isSatisfiedBy(patient: Patient): boolean {
    return new HasAllCommonSymptomsSpecification()
      .and(new HasSomeLessSymptomsSpecification())
      .not(new HasSomeSeriousSymptomsSpecification()) // Lógica não implementada
      .isSatisfiedBy(patient);
  }
}

Implemente a lógica NOT e faça as combinações que desejar e precisar.

Conclusão

Sempre que possível a utilização de um pattern para resolver um problema de lógica que se repete, ou que ficou muito complexa, é sempre bem vinda. O Specification Pattern é sempre bom quando se tem regras de negócios que são compostas por outras regras de negócio. Mas lembre-se, podemos sempre cair na otimização prematura da aplicação. Por isso, tenha cuidado ao utilizar patterns.