Quando comecei a mergulhar no mundo do desenvolvimento de software, muitas vezes me vi sobrecarregado por todos os jargões e conceitos que circulavam por aí. Um dos conceitos que parecia particularmente assustador foram os princípios SOLID. Parecia algo com que apenas os desenvolvedores “sérios” precisavam se preocupar. Mas à medida que fui ficando mais confortável com a codificação, percebi que esses princípios têm menos a ver com ser sofisticados e mais com escrever códigos que não dão vontade de arrancar os cabelos depois de alguns meses.

Então, aqui está minha opinião sobre os princípios SOLID em JavaScript - um guia prático e prático que eu gostaria de ter quando comecei.

1. Princípio de Responsabilidade Única (SRP): Uma tarefa, bem executada

O que é?

O Princípio da Responsabilidade Única afirma que uma classe deve ter apenas um motivo para mudar, o que significa que deve ter apenas um trabalho ou responsabilidade.

Analogia da vida real

Pense em um barista em sua cafeteria favorita. O trabalho deles é fazer café. Se de repente eles tiverem que começar a consertar a máquina de café expresso, servir doces e levar o lixo para fora, as coisas ficarão caóticas. Assim como o barista deve se concentrar em fazer café, sua turma deve se concentrar em fazer bem uma coisa.

Exemplo em JavaScript:

Imagine que você tem uma classe User que lida com autenticação de usuário, validação de dados e armazenamento de banco de dados. Está fazendo muito! Ao dividir essas responsabilidades em classes separadas, você torna seu código mais fácil de gerenciar e manter.

class UserAuthenticator {
  login(user) {
    // handle login
  }
}

class UserDataValidator {
  validate(user) {
    // validate user data
  }
}

class UserDatabase {
  save(user) {
    // save user to the database
  }
}

2. Princípio Aberto/Fechado (OCP): Amplie, não modifique

O que é?

O Princípio Aberto/Fechado afirma que as entidades de software devem ser abertas para extensão, mas fechadas para modificação. Em outras palavras, você poderá adicionar novas funcionalidades sem alterar o código existente.

Analogia da vida real:

Imagine seu console de jogos favorito. Você pode adicionar novos jogos, controladores e acessórios, mas não precisa abri-los e religá-los para fazer isso. Da mesma forma, você poderá adicionar novos recursos ao seu código sem alterar sua estrutura central.

Exemplo em JavaScript:

Digamos que você tenha uma classe Shape com um método para calcular a área. Se você precisar adicionar uma nova forma, como um triângulo, não deverá modificar a classe existente. Em vez disso, estenda-o.

class Shape {
  area() {
    throw "Area method not implemented";
  }
}

class Rectangle extends Shape {
  constructor(width, height) {
    super();
    this.width = width;
    this.height = height;
  }

  area() {
    return this.width * this.height;
  }
}

class Circle extends Shape {
  constructor(radius) {
    super();
    this.radius = radius;
  }

  area() {
    return Math.PI * this.radius * this.radius;
  }
}

3. Princípio de Substituição de Liskov (LSP): Mantenha-o Substituível

O que é?

O Princípio da Substituição de Liskov afirma que os objetos de uma superclasse devem ser substituídos por objetos de uma subclasse sem afetar a correção do programa.

Analogia da vida real:

Imagine alugar um carro. Quer você compre um sedã ou um SUV, espera que ele tenha as funcionalidades básicas de um carro: deve dirigir, dirigir e parar. Se o seu carro alugado exigisse um conjunto de controles completamente diferente, você estaria em apuros! Da mesma forma, as subclasses devem se comportar de uma forma que não quebre as expectativas estabelecidas por sua classe pai.

Exemplo em JavaScript:

Se você tiver uma classe Bird e uma classe Penguin que a estenda, o Penguin ainda deverá se comportar como um Bird, mesmo que não possa voar. Ele ainda deve andar, comer e talvez até nadar.

class Bird {
  move() {
    console.log("Flies in the sky");
  }
}

class Penguin extends Bird {
  move() {
    console.log("Swims in the water");
  }
}

const myBird = new Bird();
const myPenguin = new Penguin();

myBird.move(); // Flies in the sky
myPenguin.move(); // Swims in the water

4. Princípio de segregação de interface (ISP): interfaces personalizadas

O que é?

O Princípio de Segregação de Interface sugere que os clientes não devem ser forçados a implementar interfaces que não usam. Em vez de ter uma interface grande, você deve criar interfaces menores e mais específicas.

Analogia da vida real:

Imagine um restaurante onde o chef também tem que ser garçom, barman e lavador de pratos. É opressor e ineficiente! Em vez disso, cada função deve ter tarefas específicas. Da mesma forma, suas interfaces devem ser especializadas e focadas.

Exemplo em JavaScript:

Se você tiver uma interface Worker que inclua métodos como buildHouse, paintHouse e designHouse, um trabalhador que apenas pinta casas não deveria ter que implementar todos os outros métodos. Divida-o em interfaces menores.

class Builder {
  build() {
    console.log("Building house...");
  }
}

class Painter {
  paint() {
    console.log("Painting house...");
  }
}

class Designer {
  design() {
    console.log("Designing house...");
  }
}

5. Princípio de Inversão de Dependência (DIP): Confie em Abstrações

O que é?

O Princípio da Inversão de Dependência afirma que módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.

Analogia da vida real:

Pense em como você conecta o carregador do telefone a uma tomada de parede. Você não precisa conhecer os detalhes da fiação elétrica dentro das paredes – tudo que você precisa é da interface (a tomada) para alimentar seu dispositivo. Da mesma forma, seu código deve depender de abstrações (interfaces), não de implementações concretas.

Exemplo em JavaScript:

Se você tem uma classe LightBulb que controla diretamente uma classe Switch, você está criando um acoplamento forte. Em vez disso, ambos devem depender de uma interface como PowerSource.

class LightBulb {
  turnOn(powerSource) {
    powerSource.provideElectricity();
    console.log("Light is on");
  }
}

class Switch {
  constructor(powerSource) {
    this.powerSource = powerSource;
  }

  operate() {
    this.powerSource.togglePower();
  }
}

class PowerSource {
  provideElectricity() {
    console.log("Providing electricity");
  }

  togglePower() {
    console.log("Toggling power");
  }
}

Conclusão

Dominar os princípios SOLID é como aprender a cozinhar com um conjunto de receitas comprovadas. Depois de entendê-los, você poderá criar um código que não seja apenas funcional, mas elegante e fácil de manter. Então, da próxima vez que você se encontrar em um enigma de codificação, lembre-se: existe um princípio para isso!

Boa codificação! ?