DEV Community: Victor Lis Bronzo

OPEN - CLOSED PRINCIPLE

Victor Lis Bronzo — Tue, 14 Jul 2026 23:56:10 +0000

OPEN - CLOSED PRINCIPLE

The integral parts of a code should be open for extension and closed for modification.

The idea is to avoid relying on conditional checks using if-else, ternary operators, and switch.

When a new requirement arrives, you add the behavior by creating something new, without modifying the old code.

TO BE FAIR

The idea of not using conditional operators is a result of correctly applying OCP, not the focus itself.

This is because in order to not depend on these operators, excellence in applying polymorphism and abstraction is necessary.

With this, it becomes possible to couple new implementations without rewriting the already existing code.

BAD EXAMPLE

Every new payment method will cause an edit here. It makes new implementations difficult and puts the old ones at risk.

Code Example:

// BAD: Tight coupling. The class needs to be modified for each new rule.
class PaymentProcessor {
  public process(amount: number, method: 'CREDIT_CARD' | 'PIX' | 'PAYPAL'): void {
    if (method === 'CREDIT_CARD') {
      console.log(`Processing $${amount} via Credit Card...`);
      // Complex logic for acquirer integration...
    }
    else if (method === 'PIX') {
      console.log(`Processing $${amount} via Pix key...`);
      // Complex logic for QRCode generation...
    }
    else if (method === 'PAYPAL') {
      console.log(`Processing $${amount} via PayPal...`);
      // Complex redirection logic...
    }
    else {
      throw new Error('Payment method not supported.');
    }
  }
}

GOOD EXAMPLE

Just fulfill the “IPaymentMethod” contract and the method is already valid.

We can then add a “DebitCardPayment”, without affecting the other methods.

Code Example:

// 1. The Abstraction (The Contract)
interface IPaymentMethod {
  processPayment(amount: number): void;
}

// 2. The Extensions (New isolated behaviors)
class CreditCardPayment implements IPaymentMethod {
  public processPayment(amount: number): void {
    console.log(`Processing $${amount} via Credit Card...`);
  }
}

class PixPayment implements IPaymentMethod {
  public processPayment(amount: number): void {
    console.log(`Processing $${amount} via Pix key...`);
  }
}

// 3. The Closed Application (The Consumer)
class PaymentProcessor {
  public process(amount: number, paymentMethod: IPaymentMethod): void {
    paymentMethod.processPayment(amount);
  }
}

// Practical use:
const processor = new PaymentProcessor();
processor.process(150.0, new PixPayment());

IS IT REALLY THAT IMPORTANT?

Without hesitation, yes, very much!

Rework is expensive: it is wasted labor, planning, and time.

And besides that, constantly altering already “finished” code opens up more loopholes to break a business rule or feature that was already working.

My Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfolio: portfolio.victorlisbronzo.me
Coolest Portfolio: victorlisbronzo.me

Leave your reaction ❤️
Have you ever needed to refactor old code because of poorly applied OCP?

PRINCÍPIO DE ABERTO/FECHADO

Victor Lis Bronzo — Tue, 14 Jul 2026 23:54:50 +0000

OPEN - CLOSED PRINCIPLE

As partes integrantes de um código devem ser abertas para extensão e fechadas para modificações.

A ideia é evitar a dependência de verificações condicionais com if-else, operadores ternários e switch.

Quando um novo requisito chegar, você adiciona o comportamento criando algo novo, sem modificar o código antigo.

PRA SER JUSTO

A ideia de não usar operadores condicionais é um resultado de uma aplicação correta do OCP, não é o foco em si.

Isso porque para conseguir não depender desses operadores é necessário excelência na aplicação de polimorfismo e abstração.

Com isso, se torna possível acoplar novas implementações sem reescrever o código já existente.

EXEMPLO RUIM

Todo novo meio de pagamento causará uma edição aqui. Dificulta em novas implementações e põe em risco as antigas.

Exemplo de Código:

// RUIM: Forte acoplamento. A classe precisa ser modificada a cada nova regra.
class PaymentProcessor {
  public process(amount: number, method: 'CREDIT_CARD' | 'PIX' | 'PAYPAL'): void {
    if (method === 'CREDIT_CARD') {
      console.log(`Processando R$${amount} via Cartão de Crédito...`);
      // Lógica complexa de integração com a adquirente...
    }
    else if (method === 'PIX') {
      console.log(`Processando R$${amount} via chave Pix...`);
      // Lógica complexa de geração de QRCode...
    }
    else if (method === 'PAYPAL') {
      console.log(`Processando R$${amount} via PayPal...`);
      // Lógica complexa de redirecionamento...
    }
    else {
      throw new Error('Método de pagamento não suportado.');
    }
  }
}

EXEMPLO BOM

Basta cumprir o contrato “IPaymentMethod” e o método já é válido.

Conseguimos então adicionar um “DebitCardPayment”, sem afetar os demais métodos.

Exemplo de Código:

// 1. A Abstração (O Contrato)
interface IPaymentMethod {
  processPayment(amount: number): void;
}

// 2. As Extensões (Novos comportamentos isolados)
class CreditCardPayment implements IPaymentMethod {
  public processPayment(amount: number): void {
    console.log(`Processando R$${amount} via Cartão de Crédito...`);
  }
}

class PixPayment implements IPaymentMethod {
  public processPayment(amount: number): void {
    console.log(`Processando R$${amount} via chave Pix...`);
  }
}

// 3. A Aplicação Fechada (O Consumidor)
class PaymentProcessor {
  public process(amount: number, paymentMethod: IPaymentMethod): void {
    paymentMethod.processPayment(amount);
  }
}

// Uso prático:
const processor = new PaymentProcessor();
processor.process(150.0, new PixPayment());

É MESMO TÃO IMPORTANTE?

Sem titubear, sim e muito!

Retrabalho é caro: é mão de obra, planejamento e tempo desperdiçados.

E além disso, ficar constantemente alterando código já “finalizado” abre mais brechas para quebrar uma regra de negócio ou feature que já funcionava.

Meus Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfólio: portfolio.victorlisbronzo.me
Portfólio mais legal: victorlisbronzo.me

Deixe sua reação ❤️
Você já precisou refatorar código antigo por ter aplicado mal o OCP?

SINGLE RESPONSIBILITY PRINCIPLE

Victor Lis Bronzo — Mon, 13 Jul 2026 20:35:26 +0000

SINGLE RESPONSIBILITY PRINCIPLE (SRP)

A class should have one, and exclusively one, reason to change.

In other words, we shouldn't have a single class doing everything: receiving data, validating requests, applying business rules, and accessing the database...

This class that “does it all” is the famous God Class, and it is an anti-pattern.

IS IT REALLY THAT IMPORTANT?

An analogy that explains its importance well is the comparison between a Swiss Army Knife vs. a Scalpel.

I know it might sound weird at first, but let's break it down. A pocket knife can be quite useful, carrying a bunch of functionalities at once, being practical in everyday life.

But what if one tool in it breaks?

POINT FOR SPECIALIZATION

You will have to buy another one, even if all the other tools are working well. A waste, right? This applied to software is even worse.

On the other hand, the scalpel, besides having fewer chances of breaking, is a specialist in its own function. You will only replace the scalpel if it actually has a problem.

CONNECTION TO ARCHITECTURE

In practice, SRP is the foundation for organizing the structure of your project.

A class that only serves a single responsibility helps in understanding architectures like MVC, Hexagonal, Clean Arch...

This principle determines that it makes no sense to have a class that defines attributes, validates fields, saves data to the database... In this scenario, the class would assume multiple responsibilities, which violates the precepts of any of these architectures.

A BAD EXAMPLE

This class below fulfills more than one responsibility. A class that deals with persistence, validation, business rules... violates the SRP.

Code Example (The Anti-pattern):

class UserService {
  constructor(
    private name: string,
    private email: string,
  ) {}

  // Responsibility 1: Data Validation
  public validateEmail(): boolean {
    return this.email.includes("@");
  }

  // Responsibility 2: Data Persistence (Database Access)
  public saveToDatabase(): void {
    console.log(`Saving user ${this.name} to MySQL database...`);
  }

  // Responsibility 3: Sending Notifications
  public sendWelcomeEmail(): void {
    console.log(`Sending welcome email to ${this.email}...`);
  }

  // Responsibility 4: Report Generation (Presentation/Visualization)
  public generateUserReportPDF(): void {
    console.log(`Generating PDF report for ${this.name}...`);
  }

  // Responsibility 5: Infrastructure (Error Logging)
  public logSystemError(error: string): void {
    console.log(`[LOG] ${new Date().toISOString()}: ${error}`);
  }
}

AND WHAT WOULD BE A GOOD EXAMPLE?

It would be extracting all these responsibilities (Persistence, Business Rule, Validation, Boundary...) from a single class.

And exactly because of this, SRP communicates so well with architectures and their layers. Using the famous "Clean Arch" as an example, each of its layers will assume a well-defined responsibility.

Code Example (Applying SRP):

// ✅ SOLID: Each class has only one reason to change

class UserValidator {
  public isValidEmail(email: string): boolean {
    return email.includes("@");
  }
}

class UserRepository {
  public save(user: User): void {
    console.log(`Saving user ${user.name} to database...`);
  }
}

class EmailService {
  public sendWelcomeEmail(email: string): void {
    console.log(`Sending welcome email to ${email}...`);
  }
}

class ReportGenerator {
  public generateUserPDF(user: User): void {
    console.log(`Generating PDF report for ${user.name}...`);
  }
}

class Logger {
  public logError(error: string): void {
    console.log(`[LOG] ${new Date().toISOString()}: ${error}`);
  }
}

SRP + CLEAN ARCH

Each layer fulfills only its responsibility and passes it on to the next layer, following the flow. The detail is that, depending on the size of the project, the team, and the needs, the layers can increase or decrease.

ROUTE: Receives the HTTP request and directs the traffic.
CONTROLLER: Validates the input data and formats the final response.
SERVICE: Orchestrates the application rules and entities.
REPOSITORY: Isolates the database and executes the persistence.

OTHER CASES

The previous example focused on Clean Arch, but other architectural approaches, like MVC and Hexagonal, also apply SRP to their core.

SOLID acts as a foundation for these patterns, not as a competitor.

In practice, the division of responsibilities ends up being implicit in the very definition of the layers of any good architecture:
⬇️ user.route.ts
⬇️ user.controller.ts
⬇️ user.service.ts
⬇️ user.repository.ts

My Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfolio: portfolio.victorlisbronzo.me
Coolest Portfolio: victorlisbronzo.me

Leave your reaction ❤️
Had you already realized the importance of SRP?

PRINCÍPIO DA RESPONSABILIDADE ÚNICA

Victor Lis Bronzo — Mon, 13 Jul 2026 20:34:04 +0000

PRINCÍPIO DA RESPONSABILIDADE ÚNICA

Em Inglês: SINGLE RESPONSIBILITY PRINCIPLE (SRP)

Uma classe deve ter um, e exclusivamente um, motivo para ser alterada.

Ou seja, não devemos ter uma única classe fazendo de tudo: recebendo dados, validando requisições, aplicando regras de negócio e acessando o banco de dados...

Essa classe que “faz tudo” é a famosa God Class, e é um anti-pattern.

É MESMO TÃO IMPORTANTE?

Uma analogia que explica bem a importância, é a comparação entre Canivete Suíço vs. Bisturi.

Eu sei que pode soar esquisito de primeira, mas vamos destrinchar. Um canivete até pode ser bem útil, carregando um monte de funcionalidades de uma vez, sendo prático no dia a dia.

Mas e se uma ferramenta dele quebrar?

PONTO PARA ESPECIALIZAÇÃO

Você vai ter que comprar outro, mesmo que todas as outras ferramentas estejam funcionando bem. Um desperdício né? Isso aplicado em software fica pior ainda.

Já o bisturi, além de ter menos possibilidades de quebrar, ele é especialista na própria função. Você só vai trocar o bisturi, se ele realmente tiver algum problema.

CONEXÃO COM ARQUITETURA

Na prática, o SRP é a base para organizar a estrutura do seu projeto.

Uma classe que só atende a uma única responsabilidade ajuda na compreensão de arquiteturas como MVC, Hexagonal, Clean Arch...

Esse princípio determina que não faz sentido você ter uma classe que define atributos, valida campos, salva dados no banco... Nesse cenário, a classe assumiria múltiplas responsabilidades, o que viola os preceitos de qualquer uma dessas arquiteturas.

UM MAU EXEMPLO

Essa classe abaixo cumpre mais de uma responsabilidade. Uma classe que lida com persistência, validação, regras de negócio... fere o SRP.

Exemplo de Código (O Anti-pattern):

class UserService {
  constructor(
    private name: string,
    private email: string,
  ) {}

  // Responsabilidade 1: Validação de Dados
  public validateEmail(): boolean {
    return this.email.includes("@");
  }

  // Responsabilidade 2: Persistência de Dados (Acesso ao Banco de Dados)
  public saveToDatabase(): void {
    console.log(`Saving user ${this.name} to MySQL database...`);
  }

  // Responsabilidade 3: Envio de Notificações
  public sendWelcomeEmail(): void {
    console.log(`Sending welcome email to ${this.email}...`);
  }

  // Responsabilidade 4: Geração de Relatórios (Apresentação/Visualização)
  public generateUserReportPDF(): void {
    console.log(`Generating PDF report for ${this.name}...`);
  }

  // Responsabilidade 5: Infraestrutura (Log de Erros)
  public logSystemError(error: string): void {
    console.log(`[LOG] ${new Date().toISOString()}: ${error}`);
  }
}

E O QUE SERIA UM BOM EXEMPLO?

Seria extrair todas essas responsabilidades (Persistência, Regra de Negócio, Validação, Fronteira...) de uma única classe.

E justamente por isso, o SRP conversa tão bem com arquiteturas e suas camadas. Usando a famosa "Clean Arch" como exemplo, cada uma de suas camadas vai assumir uma responsabilidade bem definida.

Exemplo de Código (Aplicando o SRP):

// ✅ SOLID: Cada classe tem apenas um motivo para mudar

class UserValidator {
  public isValidEmail(email: string): boolean {
    return email.includes("@");
  }
}

class UserRepository {
  public save(user: User): void {
    console.log(`Saving user ${user.name} to database...`);
  }
}

class EmailService {
  public sendWelcomeEmail(email: string): void {
    console.log(`Sending welcome email to ${email}...`);
  }
}

class ReportGenerator {
  public generateUserPDF(user: User): void {
    console.log(`Generating PDF report for ${user.name}...`);
  }
}

class Logger {
  public logError(error: string): void {
    console.log(`[LOG] ${new Date().toISOString()}: ${error}`);
  }
}

SRP + CLEAN ARCH

Cada camada cumpre apenas sua responsabilidade e repassa para a próxima camada, seguindo o fluxo. O detalhe é que, dependendo do tamanho do projeto, da equipe e das necessidades, as camadas podem aumentar ou diminuir.

ROUTE: Recebe a requisição HTTP e direciona o tráfego.
CONTROLLER: Valida os dados de entrada e formata a resposta final.
SERVICE: Orquestra as regras da aplicação e as entidades.
REPOSITORY: Isola o banco de dados e executa a persistência.

OUTROS CASOS

O exemplo anterior focou em Clean Arch, mas outras abordagens arquiteturais, como MVC e Hexagonal, também aplicam o SRP em suas bases.

O SOLID atua como um alicerce para esses padrões, não como um concorrente.

Na prática, a divisão de responsabilidades acaba ficando implícita na própria definição das camadas de qualquer boa arquitetura:
⬇️ user.route.ts
⬇️ user.controller.ts
⬇️ user.service.ts
⬇️ user.repository.ts

Meus Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfólio: portfolio.victorlisbronzo.me
Portfólio mais legal: victorlisbronzo.me

Deixe sua reação ❤️
Você já tinha percebido a importância do SRP?

SOLID

Victor Lis Bronzo — Sat, 11 Jul 2026 17:02:15 +0000

O QUE É O SOLID?

Se você é dev e já navegou aqui na rede, provavelmente já viu dezenas de posts sobre o assunto...

Então, sendo direto, SOLID é o conjunto de 5 princípios que ajudam na melhoria da qualidade, escalabilidade e manutenção de projetos de software. E aqui na rede, vou trazer minha experiência com ele!

SINGLE RESPONSIBILITY PRINCIPLE (Princípio da Responsabilidade Única)

Uma classe deve ter um, e exclusivamente um, motivo para ser alterada.

Ou seja, não devemos ter uma única classe fazendo de tudo: recebendo dados, validando requisições, aplicando regras de negócio e acessando o banco de dados...

Essa classe que “faz tudo” é a tal da “God Class”, e é um anti-pattern.

Exemplo de Código:

// ❌ Anti-pattern: God Class fazendo muita coisa
class UserAccount {
  createAccount(user: any) {
    // 1. Valida a requisição
    if (!user.email) throw new Error("Email é obrigatório");
    // 2. Aplica as regras de negócio
    user.status = "active";
    // 3. Acessa o banco de dados
    database.save(user);
    // 4. Envia o email
    emailService.send("Bem-vindo!");
  }
}

// ✅ SOLID: Responsabilidades separadas
class UserValidator {
  validate(user: any) {
    /* lógica de validação */
  }
}
class UserRepository {
  save(user: any) {
    /* lógica de banco de dados */
  }
}
class EmailSender {
  send(message: string) {
    /* lógica de email */
  }
}

OPEN - CLOSED PRINCIPLE (Princípio Aberto-Fechado)

As partes integrantes de um código devem ser abertas para extensão e fechadas para modificações.

A ideia é evitar a dependência de verificações condicionais com if-else e switch. Quando um novo requisito chegar, você adiciona o comportamento criando algo novo, sem modificar o código antigo.

Exemplo de Código:

// ❌ Anti-pattern: Modificando código existente para cada novo tipo
class PaymentProcessor {
  process(paymentType: string, amount: number) {
    if (paymentType === "credit") {
      // processa cartão de crédito
    } else if (paymentType === "paypal") {
      // processa paypal
    } // Adicionar um novo tipo exige modificar esta classe
  }
}

// ✅ SOLID: Aberto para extensão via interfaces
interface PaymentMethod {
  process(amount: number): void;
}

class CreditCardPayment implements PaymentMethod {
  process(amount: number) {
    /* processa cartão de crédito */
  }
}

class PayPalPayment implements PaymentMethod {
  process(amount: number) {
    /* processa paypal */
  }
}

// Agora você pode adicionar novos métodos de pagamento sem tocar no código existente!

LISKOV SUBSTITUTION PRINCIPLE (Princípio da Substituição de Liskov)

Uma classe mãe deve ser capaz de ser substituída pelas suas classes filhas sem que a aplicação quebre.

Isso na prática ajuda a organizar a ideia de herança, já que nos faz evitar estender uma classe mãe, apenas para depois remover um método já implementado ou fazer um throw new Error('Not implemented'). Fazendo com que tenhamos mais cuidado no planejamento.

Exemplo de Código:

// ❌ Anti-pattern: Quebrando a substituição
class Bird {
  fly() {
    console.log("Voando...");
  }
}

class Penguin extends Bird {
  fly() {
    throw new Error("Não implementado: Pinguins não podem voar");
  }
}

// ✅ SOLID: Melhor planejamento com abstrações
class Bird {
  eat() {
    console.log("Comendo...");
  }
}

class FlyingBird extends Bird {
  fly() {
    console.log("Voando...");
  }
}

class Penguin extends Bird {
  swim() {
    console.log("Nadando...");
  }
}

INTERFACE SEGREGATION PRINCIPLE (Princípio da Segregação da Interface)

Nenhuma classe deve ser dependente de métodos que não precisa.

Um exemplo seria uma interface "Máquina", que força os métodos print(), scan(), e fax(). Nem toda máquina tem esses 3 métodos.

Então criamos as interfaces IPrinter, IScanner e IFax. Agora uma máquina assina apenas os contratos que realmente precisa e cumpre.

Exemplo de Código:

// ❌ Anti-pattern: Forçando métodos desnecessários
interface IMachine {
  print(): void;
  scan(): void;
  fax(): void;
}

class SimplePrinter implements IMachine {
  print() {
    console.log("Imprimindo...");
  }
  scan() {
    throw new Error("Não suportado");
  } // Não precisa disso
  fax() {
    throw new Error("Não suportado");
  } // Não precisa disso
}

// ✅ SOLID: Interfaces segregadas
interface IPrinter {
  print(): void;
}
interface IScanner {
  scan(): void;
}
interface IFax {
  fax(): void;
}

class SimplePrinter implements IPrinter {
  print() {
    console.log("Imprimindo...");
  }
}

class MultiFunctionPrinter implements IPrinter, IScanner, IFax {
  print() {
    console.log("Imprimindo...");
  }
  scan() {
    console.log("Escaneando...");
  }
  fax() {
    console.log("Enviando Fax...");
  }
}

DEPENDENCY INVERSION PRINCIPLE (Princípio da Inversão de Dependência)

Módulos de alto nível não devem depender de detalhes de baixo nível. Ambos devem depender de abstrações (interfaces).

Ou seja, em vez da sua classe instanciar diretamente uma conexão com o banco de dados ou serviço externo, ela deve receber isso de fora. É essa inversão que permite criar mocks para testes ou trocar ferramentas no backend sem quebrar a sua regra de negócio.

Exemplo de Código:

// ❌ Anti-pattern: Módulo de alto nível depende de detalhe de baixo nível
class MySQLDatabase {
  save(data: any) {
    /* salva no MySQL */
  }
}

class UserService {
  private db = new MySQLDatabase(); // Acoplamento forte

  createUser(user: any) {
    this.db.save(user);
  }
}

// ✅ SOLID: Dependendo de abstrações injetadas de fora
interface IDatabase {
  save(data: any): void;
}

class MySQLDatabase implements IDatabase {
  save(data: any) {
    /* salva no MySQL */
  }
}

class MongoDatabase implements IDatabase {
  save(data: any) {
    /* salva no Mongo */
  }
}

class UserService {
  // Recebe a dependência de fora (Injeção de Dependência)
  constructor(private db: IDatabase) {}

  createUser(user: any) {
    this.db.save(user);
  }
}

INDO MAIS A FUNDO

O SOLID é um conjunto de princípios complexos, e não dá pra resumir tudo em um simples amontoado de frases.

É necessário pesquisar, ler, praticar, interpretar... Então pretendo trazer por aqui uma série de novos conteúdos, destrinchando em detalhes. Pelo menos 1 tópico por princípio, com detalhes, exemplos e código.

Meus Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfólio: portfolio.victorlisbronzo.me
Portfólio mais legal: victorlisbronzo.me

Deixe sua reação ❤️
Qual desses 5 princípios você acha mais difícil de aplicar no seu dia a dia?

SOLID

Victor Lis Bronzo — Fri, 10 Jul 2026 16:41:37 +0000

WHAT IS SOLID?

If you are a dev and have browsed this network, you've probably seen dozens of posts about this topic...

So, straight to the point, SOLID is a set of 5 principles that help improve the quality, scalability, and maintainability of software projects. And here on this network, I will share my experience with it!

SINGLE RESPONSIBILITY PRINCIPLE

A class should have one, and exclusively one, reason to change.

In other words, we shouldn't have a single class doing everything: receiving data, validating requests, applying business rules, and accessing the database...

This class that “does it all” is the so-called “God Class”, and it is an anti-pattern.

Code Example:

// ❌ Anti-pattern: God Class doing too much
class UserAccount {
  createAccount(user: any) {
    // 1. Validates request
    if (!user.email) throw new Error("Email is required");
    // 2. Applies business rules
    user.status = "active";
    // 3. Accesses the database
    database.save(user);
    // 4. Sends email
    emailService.send("Welcome!");
  }
}

// ✅ SOLID: Separated responsibilities
class UserValidator {
  validate(user: any) { /* validation logic */ }
}
class UserRepository {
  save(user: any) { /* DB logic */ }
}
class EmailSender {
  send(message: string) { /* email logic */ }
}

OPEN - CLOSED PRINCIPLE

The integral parts of a code should be open for extension and closed for modification.

The idea is to avoid relying on conditional checks using if-else and switch. When a new requirement arrives, you add the behavior by creating something new, without modifying the old code.

Code Example:

// ❌ Anti-pattern: Modifying existing code for every new type
class PaymentProcessor {
  process(paymentType: string, amount: number) {
    if (paymentType === "credit") {
      // process credit card
    } else if (paymentType === "paypal") {
      // process paypal
    } // Adding a new type requires modifying this class
  }
}

// ✅ SOLID: Open for extension via interfaces
interface PaymentMethod {
  process(amount: number): void;
}

class CreditCardPayment implements PaymentMethod {
  process(amount: number) { /* process credit card */ }
}

class PayPalPayment implements PaymentMethod {
  process(amount: number) { /* process paypal */ }
}

// Now you can add new payment methods without touching existing code!

LISKOV SUBSTITUTION PRINCIPLE

A parent class must be able to be substituted by its child classes without breaking the application.

In practice, this helps to organize the idea of inheritance, as it prevents us from extending a parent class only to later remove an already implemented method or do a throw new Error('Not implemented'). Making us much more careful during planning.

Code Example:

// ❌ Anti-pattern: Breaking substitution
class Bird {
  fly() { console.log("Flying..."); }
}

class Penguin extends Bird {
  fly() {
    throw new Error('Not implemented: Penguins cannot fly');
  }
}

// ✅ SOLID: Better planning with abstractions
class Bird {
  eat() { console.log("Eating..."); }
}

class FlyingBird extends Bird {
  fly() { console.log("Flying..."); }
}

class Penguin extends Bird {
  swim() { console.log("Swimming..."); }
}

INTERFACE SEGREGATION PRINCIPLE

No class should be dependent on methods it doesn't need.

An example would be a "Machine" interface that forces the methods print(), scan(), and fax(). Not every machine has these 3 methods.

So we create the interfaces IPrinter, IScanner, and IFax. Now a machine signs only the contracts it actually needs and fulfills.

Code Example:

// ❌ Anti-pattern: Forcing unnecessary methods
interface IMachine {
  print(): void;
  scan(): void;
  fax(): void;
}

class SimplePrinter implements IMachine {
  print() { console.log("Printing..."); }
  scan() { throw new Error("Not supported"); } // Doesn't need this
  fax() { throw new Error("Not supported"); }  // Doesn't need this
}

// ✅ SOLID: Segregated interfaces
interface IPrinter { print(): void; }
interface IScanner { scan(): void; }
interface IFax { fax(): void; }

class SimplePrinter implements IPrinter {
  print() { console.log("Printing..."); }
}

class MultiFunctionPrinter implements IPrinter, IScanner, IFax {
  print() { console.log("Printing..."); }
  scan() { console.log("Scanning..."); }
  fax() { console.log("Faxing..."); }
}

DEPENDENCY INVERSION PRINCIPLE

High-level modules should not depend on low-level details. Both should depend on abstractions (interfaces).

In other words, instead of your class directly instantiating a connection to the database or an external service, it should receive it from the outside. It is this inversion that allows creating mocks for tests or swapping tools in the backend without breaking your business rules.

Code Example:

// ❌ Anti-pattern: High-level module depends on low-level detail
class MySQLDatabase {
  save(data: any) { /* saves to MySQL */ }
}

class UserService {
  private db = new MySQLDatabase(); // Tight coupling

  createUser(user: any) {
    this.db.save(user);
  }
}

// ✅ SOLID: Depending on abstractions injected from the outside
interface IDatabase {
  save(data: any): void;
}

class MySQLDatabase implements IDatabase {
  save(data: any) { /* saves to MySQL */ }
}

class MongoDatabase implements IDatabase {
  save(data: any) { /* saves to Mongo */ }
}

class UserService {
  // Receives the dependency from outside (Dependency Injection)
  constructor(private db: IDatabase) {} 

  createUser(user: any) {
    this.db.save(user);
  }
}

GOING DEEPER

SOLID is a set of complex principles, and you can't summarize everything in a simple bunch of sentences.

It is necessary to research, read, practice, interpret... So I intend to bring a series of new content here, unraveling them in detail. At least 1 topic per principle, with details, examples, and code.

My Links
Github: victor-lis-bronzo
Linkedin: victor-lis-bronzo
Portfolio: portfolio.victorlisbronzo.me
Coolest Portfolio: victorlisbronzo.me

Leave your reaction ❤️
Which of these 5 principles do you find the most difficult to apply in your daily life?