DEV Community: Victor Lima Reboredo

Da Observabilidade ao FinOps: Como Tornar Custos uma Métrica de Engenharia

Victor Lima Reboredo — Tue, 09 Jun 2026 14:43:59 +0000

Se você atua com engenharia de software ou infraestrutura há algum tempo, provavelmente se lembra de quando provisionar capacidade computacional era um exercício essencialmente baseado em CAPEX (Capital Expenditure). Escalar um sistema significava preencher planilhas de especificação, submeter requisições de compra e aguardar a entrega dos componentes físicos da infraestrutura. Depois de todo esse esforço logístico, ainda era preciso calcular a depreciação de cada ativo ao longo dos anos. O resultado era um ambiente altamente previsível, mas dolorosamente engessado. Qualquer tentativa de evolução na arquitetura esbarrava na lentidão da própria infraestrutura.

A quebra desse modelo aconteceu quando paramos de imobilizar capital em infraestrutura física e começamos a consumir capacidade computacional sob demanda. O movimento cloud-native virou a chave da indústria para o OPEX (Operational Expenditure). A infraestrutura deixou de ser um ativo estático em data centers para se tornar efêmera, descrita puramente em código e consumida sob demanda. Já não precisávamos adivinhar a carga do ano seguinte, bastava ajustar o provisionamento para o tráfego do dia.

Essa mudança alcançou um novo patamar com a consolidação do Kubernetes. Ao abstrair o hardware subjacente e oferecer blocos básicos como Pods, Deployments e ReplicaSets, a plataforma simplificou significativamente a orquestração de containers em escala. O que antes exigia semanas de configuração manual e alinhamento entre times, simplificou-se em declarações YAML. Provisionar ambientes complexos e definir regras de auto-scaling deixou de ser um gargalo operacional para se consolidar como o padrão operacional. Porém, a mesma abstração que trouxe ganhos expressivos de produtividade também introduziu um desafio relevante na camada de negócios: a desconexão entre as decisões arquiteturais e a previsibilidade financeira.

Quando delegamos ao plano de controle do Kubernetes a responsabilidade de gerenciar recursos automaticamente, o provisionamento deixa de ser determinístico. Em clusters modernos, o consumo de CPU, memória e largura de banda varia continuamente, influenciado por fatores como picos de tráfego, contenção entre workloads, limitações de rede e comportamentos emergentes de microsserviços interconectados.

Diante dessa volatilidade, a resposta típica dos times de engenharia é o overprovisioning — o super-dimensionamento de recursos como estratégia defensiva contra degradação de performance e violações de SLA. Embora operacionalmente eficaz na redução de riscos, essa abordagem frequentemente desloca o problema para outra dimensão: o custo, que cresce de forma contínua e muitas vezes imperceptível.

É justamente nesse ponto que o FinOps ganha relevância. Mais do que um conjunto de práticas financeiras aplicadas à tecnologia, ele surge como uma disciplina de engenharia voltada para a gestão eficiente de ambientes em nuvem. Se a infraestrutura moderna possui uma natureza inerentemente dinâmica, sua governança precisa ser orientada por dados capazes de traduzir essa complexidade em decisões concretas.

Para arquitetar sistemas eficientes tanto técnica quanto financeiramente, código e infraestrutura precisam estar integrados com ferramentas avançadas de observabilidade orientada a dados. Gerenciar a variabilidade operacional requer, fundamentalmente, visibilidade granular em tempo real.

A Anatomia do Desperdício: O Conflito entre Segurança e Eficiência

A discussão sobre custos em Kubernetes normalmente começa nas ferramentas de observabilidade ou nos relatórios de faturamento. O problema, porém, nasce muito antes disso: na forma como recursos são alocados dentro do cluster.

Em arquiteturas baseadas em microsserviços, cada container declara seus requests e limits, definindo respectivamente a quantidade mínima de recursos que deve receber e o teto máximo que poderá consumir. Essas primitivas são fundamentais para que o scheduler distribua cargas de trabalho de maneira eficiente pelos Nodes do cluster.

No papel, o modelo é elegante. Com informações precisas sobre consumo, o Kubernetes consegue realizar um bin-packing eficiente, aumentando a utilização da infraestrutura sem comprometer a estabilidade das aplicações. O desafio é que essas configurações precisam ser definidas antes que o sistema enfrente as condições reais de operação.

É nesse ponto que a incerteza entra em cena. Quando um engenheiro define os recursos de um Deployment, raramente está pensando no comportamento médio da aplicação. O foco costuma estar nos cenários extremos. Ninguém quer descobrir em produção que um pico inesperado de consumo resultou em um OOMKilled, encerrando containers por falta de memória, ou em CPU Throttling, degradando silenciosamente a performance da aplicação e aumentando sua latência.

Diante desse risco, o comportamento mais comum é adotar margens de segurança generosas. Como o tráfego oscila, cargas de processamento variam e dependências externas introduzem imprevisibilidade adicional, os valores configurados passam a refletir o pior cenário imaginado, e não o comportamento observado na maior parte do tempo.

O resultado é um padrão recorrente em ambientes Kubernetes maduros: recursos são reservados para garantir resiliência, mas permanecem ociosos durante grande parte do ciclo de vida da aplicação. Não é incomum encontrar clusters operando com baixa utilização efetiva de CPU e memória enquanto o scheduler continua incapaz de acomodar novas cargas porque, do ponto de vista lógico, a capacidade disponível já foi comprometida pelos requests declarados.

Esse é o paradoxo central da eficiência em ambientes distribuídos. Quanto maior a preocupação com estabilidade, maior tende a ser a reserva preventiva de recursos. E quanto maior a reserva preventiva, maior a distância entre a infraestrutura que está sendo paga e a infraestrutura que está sendo efetivamente utilizada.

O Desafio da Visibilidade em Ambientes Compartilhados

Identificar esse desperdício é muito mais difícil do que parece. As ferramentas tradicionais de observabilidade foram projetadas para responder perguntas operacionais: utilização de CPU, consumo de memória, disponibilidade, latência e taxa de erros. Elas são excelentes para explicar o comportamento técnico do sistema, mas não foram concebidas para responder quanto esse comportamento custa.

Ao mesmo tempo, o provedor de nuvem possui a visão oposta. Ele conhece detalhadamente o custo da infraestrutura subjacente — quantas horas um determinado Node permaneceu ativo, qual foi o consumo de armazenamento ou quanto tráfego saiu da rede —, mas não entende como esses recursos foram distribuídos entre aplicações, equipes ou produtos. Entre essas duas perspectivas existe uma lacuna.

O Kubernetes opera sobre um modelo de shared tenancy, no qual dezenas ou centenas de workloads compartilham a mesma infraestrutura física. Quando a fatura chega no fim do mês, ela representa o custo agregado do cluster, mas não revela quais aplicações consumiram mais recursos, quais ambientes estão superdimensionados ou quais serviços concentram a maior parcela da ociosidade.

É justamente dessa necessidade que surge a camada analítica do FinOps.

Construir uma operação orientada por dados significa conectar o mundo financeiro ao mundo operacional, correlacionando custos de infraestrutura com métricas de utilização do cluster. Somente a partir dessa correlação é possível responder perguntas que realmente orientam decisões de otimização.

Quanto da capacidade provisionada está sendo efetivamente utilizada? Quanto estamos pagando por recursos reservados, mas raramente consumidos? Como distribuir custos compartilhados entre aplicações, equipes e produtos de maneira consistente?

Essas perguntas parecem financeiras, mas sua origem é essencialmente técnica. Sem essa visibilidade, a organização continua operando no escuro. Qualquer iniciativa de redução de custos se transforma em um exercício de tentativa e erro, onde a busca por economia compete diretamente com a estabilidade do ambiente. O desafio do FinOps, portanto, não é apenas reduzir despesas, mas transformar a complexidade operacional do cluster em informações confiáveis para tomada de decisão.

A Ponte entre o Kubelet e o Cartão de Crédito: Observabilidade na Prática

Se o desperdício nasce da distância entre o que é provisionado e o que é efetivamente utilizado, a solução passa necessariamente por visibilidade.

O desafio é que os dados necessários para entender essa diferença estão fragmentados. De um lado, o Kubernetes conhece detalhadamente o comportamento dos workloads: quanto CPU e memória cada aplicação solicita, quanto realmente consome e como esses recursos são distribuídos ao longo do tempo. Do outro, o provedor de nuvem enxerga apenas a infraestrutura faturada: instâncias, armazenamento, tráfego de rede e demais componentes que compõem a conta mensal.

Enquanto essas duas perspectivas permanecem isoladas, o custo continua sendo uma consequência difícil de explicar. Sabemos quanto pagamos e sabemos como o cluster se comporta, mas não conseguimos relacionar uma informação à outra.

É justamente essa lacuna que as plataformas de observabilidade voltadas para FinOps procuram preencher.

O primeiro passo não envolve dashboards ou relatórios sofisticados, mas organização. Em um ambiente distribuído, custo sem contexto tem pouco valor. Para que seja possível atribuir consumo a produtos, equipes ou serviços específicos, a infraestrutura precisa ser descrita de forma consistente. Labels, annotations e namespaces deixam de ser apenas metadados operacionais e passam a funcionar como mecanismos de rastreabilidade.

Com essa base estabelecida, torna-se possível correlacionar duas dimensões que normalmente vivem separadas: utilização e faturamento. O consumo real observado dentro do cluster passa a ser associado aos custos da infraestrutura subjacente, revelando não apenas quanto uma aplicação custa, mas também quanto da capacidade reservada permanece ociosa.

Essa visibilidade transforma completamente a tomada de decisão.

Sem dados, o dimensionamento de recursos tende a ser guiado pelo receio de indisponibilidade. Com dados, ele passa a refletir o comportamento observado da aplicação. Em vez de provisionar para cenários hipotéticos, as equipes conseguem ajustar alocações com base em padrões reais de utilização, reduzindo desperdícios sem comprometer a estabilidade.

Na prática, a observabilidade financeira não existe para produzir relatórios mais elaborados. Sua principal função é substituir intuição por evidência. Quando a engenharia consegue enxergar simultaneamente consumo, utilização e custo, o problema deixa de ser uma discussão abstrata sobre otimização e passa a ser uma questão mensurável.

É nesse momento que o FinOps deixa de ser uma iniciativa financeira e se consolida como uma disciplina de engenharia. O objetivo não é simplesmente gastar menos, mas criar mecanismos que permitam equilibrar, de forma contínua, eficiência operacional, confiabilidade e custo.

A Fatura Também é uma Métrica

Durante muito tempo, as responsabilidades da engenharia estiveram concentradas em atributos técnicos bem definidos: disponibilidade, performance, escalabilidade e segurança. A adoção massiva da nuvem não eliminou essas preocupações, mas adicionou uma nova variável à equação: o custo operacional.

Em ambientes cloud-native, decisões arquiteturais possuem consequências financeiras diretas. Um serviço superdimensionado, uma política de auto-scaling inadequada ou uma reserva excessiva de recursos não afetam apenas a eficiência técnica do sistema; impactam também a forma como a organização converte infraestrutura em valor de negócio.

É justamente por isso que FinOps não deve ser interpretado como uma iniciativa exclusivamente financeira. Na prática, trata-se da extensão natural da observabilidade para uma dimensão que, durante muito tempo, permaneceu invisível para a engenharia.

Ao longo deste artigo, vimos que a imprevisibilidade dos ambientes distribuídos leva equipes a adotarem margens de segurança cada vez maiores. Vimos também que, sem dados adequados, distinguir resiliência de desperdício se torna uma tarefa quase impossível. A observabilidade financeira surge exatamente para preencher essa lacuna, conectando o comportamento do sistema aos custos gerados por ele.

A boa notícia é que essa mudança não começa com uma nova ferramenta nem com um projeto corporativo de grande porte. Ela começa com perguntas simples.

Os requests e limits dos seus serviços refletem o comportamento real da aplicação ou apenas uma estimativa conservadora criada anos atrás? Os recursos do cluster possuem metadados suficientes para permitir rastreabilidade de custos? Sua equipe consegue identificar quanto da capacidade provisionada está efetivamente sendo utilizada?

Responder essas perguntas costuma revelar oportunidades de otimização mais rapidamente do que qualquer iniciativa isolada de redução de custos.

No fim, a principal mudança proposta pelo FinOps é de perspectiva. Em um ambiente onde infraestrutura pode ser provisionada em segundos e consumida continuamente, a fatura deixa de ser apenas um relatório financeiro produzido no fim do mês. Ela passa a ser mais uma fonte de observabilidade sobre o sistema.

E, assim como acontece com latência, disponibilidade ou taxa de erro, aquilo que pode ser observado também pode ser compreendido, otimizado e evoluído.

Explorando Golang com olhos de um dev sênior em TypeScript

Victor Lima Reboredo — Mon, 12 May 2025 19:11:28 +0000

Introdução

Como desenvolvedor sênior em TypeScript, passei anos imerso em um ecossistema altamente expressivo, dinâmico e repleto de ferramentas que facilitam o desenvolvimento web moderno. TypeScript me oferece tipagem estática poderosa, integração nativa com bibliotecas JavaScript, e uma curva de aprendizado suave para quem vem do mundo do JS. No entanto, recentemente, decidi encarar um novo desafio: aprender Golang.

Há alguns anos venho atuando no desenvolvimento de software e, nesse tempo, acumulei uma boa variedade de experiências. Já mergulhei em código legado — alguns verdadeiramente marcantes, como sistemas escritos em Clipper (xBase) — e também trabalhei com stacks bem mais "moderninhas", como Python e TypeScript, usando até o Deno em alguns projetos.

Entre todas as linguagens com as quais tive contato, a que mais me conquistou, sem a menor dúvida, foi o TypeScript. E não, não estou falando apenas de usar React (sim, estou sendo um pouco pejorativo aqui) para montar páginas web e controlar estados como um verdadeiro "front-enzo". Minha atuação foi principalmente front-end, mas sempre amei estar no back-end também e me aprofundei consideravelmente nesse ecossistema, explorando o Node.js, Deno e - mais recentemente - a runtime Bun.

Já estive à frente da construção de servidores back-end que conversavam com bancos relacionais — em sua maioria — tanto com frameworks completos como o NestJS quanto com servidores mais leves e "crus", usando Express ou Fastify. Todas essas experiências foram extremamente enriquecedoras e moldaram muito da forma como penso e escrevo código hoje. Além disso, foi com essa linguagem que pude colocar em prática pensamentos meio soltos relacionados à arquitetura de um software e até ao design de código dos projetos que criei (a maioria privado, mas muita coisa disponível publicamente). Estudar Programação Orientada a Objetos — que era o foco principal da minha abordagem com TS — e também revisitar a programação procedural foi uma ótima experiência que eu tive com o typescript. Tem sido um forte companheiro nesses poucos anos de carreira.

De um tempo para cá, estava ouvindo alguns ótimos podcasts como o Código Fonte TV, Café Debug e assistindo os vídeos do mano Deyvin para distrair a mente e me ocorreu que eu estava há um tempo em minhas "zonas" de conforto. Sempre a mesma stack: postgres ou mysql com typescript ou python. A única variação era a lib, ou até o método de abordagem. As perguntas eram sempre: "Ah, vou usar sequelize (gosto mais de typeorm e sqlalchemy para python) como ORM? Aliás, vou usar ORM ou faço algo mais hard com sanitização de queries, etc?", então "Bom, eu posso usar um PDO com doctrine ou ZendFramework/Laravel?" ou então "Faço um monolito, microsserviços, monorepo?" - sim, às vezes é um saco ser pleno e ainda ter algumas dúvidas infantis.

Pensando nisso, comecei a me aventurar a descobrir novos horizontes. Quer dizer, o mundo da tecnologia é tão amplo e sofisticado. Nunca temos uma resposta definitiva, há sempre algo apropriado para um problema específico. Mas mesmo assim, todos os dias surgem coisas novas e tentam matar outras coisas (RIP Flutter). Em minhas pesquisas pessoais e buscas por mais conteúdo profundo sobre programação, além de ter me dedicado a mais estudos referentes a estruturas de dados e algoritmos, me deparei com linguagens de mais "baixo nível". Eu na verdade, as chamo de nível médio kkkkkk. Dentre elas: zig, rust e a linguagem que dedico esse post: golang.

Aprender golang está sendo um desafio extremamente prazeroso e tenho conseguido estar mais perto de problemas que, linguagens quase que humanas como python e typescript, nos suprimem de conhecer. Algumas coisas interessantes são os controles de threads, os controles de erros (quando descobri que golang não tinha try/catch minha mente deu uma explodida, confesso) e até mesmo a manipulação intensiva de ponteiros e seu uso dinâmico. Mas vamos por partes...

Logo de cara, o contraste entre as duas linguagens é significativo. Golang é realmente minimalista por natureza, e eu achava que isso era uma espécie de sensacionalismo. É impressionante como que escrevendo pouco, as coisas tomam forma de maneira bem fluída e simples. Ele remove toda a "mágica" que frameworks e abstrações em TypeScript muitas vezes introduzem, forçando você a pensar de maneira mais direta, próxima ao metal. A ausência inicial de generics (que felizmente agora fazem parte da linguagem), o modelo de concorrência com goroutines e channels, e até mesmo a maneira pragmática como erros são tratados (sem exceções!) representam uma nova mentalidade.

Há algum tempo atrás vinha escrevendo sobre conceitos-chave da orientação a objetos e do mundo de linguagens de alto nível. Mas golang é uma linguagem pragmática, que se utiliza fortemente de padrões de programação funcional e procedural, o que foi uma quebra de padrões para mim, mais acostumado com o foco em OO que tive com TS. Aprender Go é como reaprender a programar com foco em simplicidade e performance. Tudo parece mais enxuto, mais pragmático — às vezes até cru. Mas é exatamente aí que mora a beleza da linguagem. Ela é rápida, consistente e feita sob medida para sistemas concorrentes, APIs robustas e aplicações de back-end em larga escala. Quando cheguei nas coisas mais específicas do go, tais como defer, goroutines, channels e paralelismo, tive um pouco de dor de cabeça. Nada muito horrível de entender, mas como muitas coisas um Java da vida vai sintetizar e "mastigar" pra gente, nós não pensamos tanto. Mas quando chegamos em uma linguagem como golang, devemos estar atentos a literalmente TODAS as coisas. Além de todas essas coisas um detalhe me salta os olhos: o compilador e linter do golang deixam o código extramemente belo e legível ao forçar um padrão consistente. Ainda tenho muito a aprender, sei disso, mas devo dizer que tem sido incrível!

Conclusão

Agora, já tenho 3 projetos em golang que deixei público e que são frutos de migrações de code-bases escritas essencialmente em typescript e tenho gostado muito dos resultados. Linguagens de programação não deveriam, definitivamente, existir para serem pivôs de richas infantis na internet sobre qual é melhor e qual é pior. Consigo perceber que Golang não substitui outras linguagens — ele complementa. Enquanto python, java, node e até C# brilham em produtividade e expressividade, Go se destaca em performance, escalabilidade e manutenibilidade em ambientes de alto desempenho. Basta você escolher a melhor para auxiliar sua abordagem.

Link para meu github

#golang #webdev #bolhadev #carrer #carreira

(D): Aplicando o "Princípio da Inversão de Dependências" com Typescript e Java

Victor Lima Reboredo — Mon, 25 Nov 2024 21:02:18 +0000

Conceitos

SOLID é um acrônimo que representa cinco princípios fundamentais da programação orientada a objetos, propostos por Robert C. Martin - o uncle Bob. Aqui você pode ler mais sobre o artigo dele.
Esses princípios têm como objetivo melhorar a estrutura e a manutenção do código, tornando-o mais flexível, escalável e fácil de entender. Tais princípios auxiliam o programador a criar códigos mais organizados, dividindo responsabilidades, reduzindo dependências, simplificando o processo de refatoração e promovendo a reutilização do código.

O "D" do acrônimo significa "Dependency Inversion Principle". A frase que o uncle bob utilizou para definir esse princípio foi:

"Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações"

O Princípio da Inversão de Dependências visa reduzir o acoplamento entre os componentes de um sistema, promovendo maior flexibilidade, manutenibilidade e testabilidade.

Problemas que o DIP Resolve

Acoplamento rígido: Quando um módulo depende diretamente de uma implementação concreta, mudanças nessa implementação podem afetar outros módulos.
Dificuldade de testes: Testar unidades de código acopladas diretamente a implementações específicas é mais complicado, pois exige o uso dessas implementações concretas, dificultando a criação de mocks ou stubs.
Baixa reusabilidade: Um módulo altamente acoplado a detalhes concretos é menos reutilizável em outros contextos.

Aplicação Prática

Vamos criar um código responsável por enviar notificações via e-mail, de modo a analisar os problemas e as soluções possíveis para os solucionar

Java

class EmailService {
    public void sendEmail(String message) {
        System.out.println("Sending email: " + message);
    }
}

class Notification {
    private EmailService emailService;

    public Notification() {
        this.emailService = new EmailService();
    }

    public void notify(String message) {
        this.emailService.sendEmail(message);
    }
}

// Uso
public class Main {
    public static void main(String[] args) {
        Notification notification = new Notification();
        notification.notify("Welcome to our service!");
    }
}

Typescript

class EmailService {
    sendEmail(message: string): void {
        console.log(`Sending email: ${message}`);
    }
}

class Notification {
    private emailService: EmailService;

    constructor() {
        this.emailService = new EmailService();
    }

    notify(message: string): void {
        this.emailService.sendEmail(message);
    }
}

// Uso
const notification = new Notification();
notification.notify("Welcome to our service!");

Problemas:

A classe Notification depende diretamente de uma implementação concreta (EmailService).
Se quisermos mudar o canal de notificação (ex.: SMS), precisamos alterar o código de Notification.

Soluções e Benefícios:

Notification não precisa saber detalhes sobre como a mensagem é enviada.
Facilidade de substituir ou adicionar novos canais de comunicação.
Podemos testar Notification isoladamente, sem depender de implementações reais.

Java

public interface MessageService {
    void sendMessage(String message);
}

public class EmailService implements MessageService {
    @Override
    public void sendMessage(String message) {
        System.out.println("Sending email: " + message);
    }
}

public class SMSService implements MessageService {
    @Override
    public void sendMessage(String message) {
        System.out.println("Sending SMS: " + message);
    }
}

public class Notification {
    private final MessageService messageService;

    public Notification(MessageService messageService) {
        this.messageService = messageService;
    }

    public void notify(String message) {
        messageService.sendMessage(message);
    }
}

// Uso
public class Main {
    public static void main(String[] args) {
        Notification emailNotification = new Notification(new EmailService());
        emailNotification.notify("Welcome via Email!");

        Notification smsNotification = new Notification(new SMSService());
        smsNotification.notify("Welcome via SMS!");
    }
}

Typescript

interface MessageService {
    sendMessage(message: string): void;
}

class EmailService implements MessageService {
    sendMessage(message: string): void {
        console.log(`Sending email: ${message}`);
    }
}

class SMSService implements MessageService {
    sendMessage(message: string): void {
        console.log(`Sending SMS: ${message}`);
    }
}

class Notification {
    private messageService: MessageService;

    constructor(messageService: MessageService) {
        this.messageService = messageService;
    }

    notify(message: string): void {
        this.messageService.sendMessage(message);
    }
}

// Uso
const emailNotification = new Notification(new EmailService());
emailNotification.notify("Welcome via Email!");

const smsNotification = new Notification(new SMSService());
smsNotification.notify("Welcome via SMS!");

3. Testes Unitários

Java

public class MockMessageService implements MessageService {
    @Override
    public void sendMessage(String message) {
        System.out.println("Mock message sent: " + message);
    }
}

// Teste com o mock
public class Main {
    public static void main(String[] args) {
        MessageService mockMessageService = new MockMessageService();
        Notification mockNotification = new Notification(mockMessageService);
        mockNotification.notify("Test message");
    }
}

Typescript

class MockMessageService implements MessageService {
    sendMessage(message: string): void {
        console.log(`Mock message sent: ${message}`);
    }
}

// Teste com o mock
const mockNotification = new Notification(new MockMessageService());
mockNotification.notify("Test message");

Conclusão

O Princípio da Inversão de Dependências (DIP) é um pilar fundamental para projetos flexíveis e robustos. Ele permite reduzir o acoplamento entre classes, facilitar a reutilização de código e melhorar a testabilidade das aplicações. Ao depender de abstrações, seu sistema se torna mais adaptável a mudanças e expansível com novas funcionalidades. O exemplo prático demonstrou como pequenos ajustes no design podem resolver problemas recorrentes de manutenção. Aplicar o DIP em conjunto com outros princípios SOLID garante um código mais limpo e preparado para o crescimento. Adotar esses conceitos é essencial para desenvolvedores que buscam excelência em arquitetura de software.

Referências Bibliográficas

Martin, Robert C. Agile Software Development, Principles, Patterns, and Practices. Prentice Hall, 2002.
Thiago Leite e Carvalho. Orientação a Objetos. Casa do Código, 2014.

(I): Aplicando o "Princípio da Segregação da Interface" com Typescript e Java

Victor Lima Reboredo — Mon, 25 Nov 2024 20:40:42 +0000

Conceitos

O "I" do acrônimo significa "Interface Segregation Principle". A frase que o uncle bob utilizou para definir esse princípio foi:

"Nenhum cliente deve ser forçado a depender de interfaces que não utiliza"

O Princípio da Segregação da Interface aborda um problema comum: interfaces excessivamente grandes que forçam implementações desnecessárias em classes que não precisam delas.

Aplicação prática

Imagine um sistema de autenticação em uma aplicação, onde diferentes métodos são usados para autenticar um usuário (e.g., por senha, por biometria, por QR Code).

Primeiro, vejamos a aplicação dessa classe sem utilizar o ISP em Java e Typescript:

Java

interface Authenticator {
    boolean authenticateWithPassword(String userId, String password);
    boolean authenticateWithBiometrics(String userId);
    boolean authenticateWithQRCode(String qrCode);
}

class PasswordAuthenticator implements Authenticator {
    @Override
    public boolean authenticateWithPassword(String userId, String password) {
        System.out.println("Authenticating with password...");
        return true;
    }

    @Override
    public boolean authenticateWithBiometrics(String userId) {
        throw new UnsupportedOperationException("Not implemented");
    }

    @Override
    public boolean authenticateWithQRCode(String qrCode) {
        throw new UnsupportedOperationException("Not implemented");
    }
}

Typescript

interface Authenticator {
  authenticateWithPassword(userId: string, password: string): boolean;
  authenticateWithBiometrics(userId: string): boolean;
  authenticateWithQRCode(qrCode: string): boolean;
}

class PasswordAuthenticator implements Authenticator {
  authenticateWithPassword(userId: string, password: string): boolean {
    console.log("Authenticating with password...");
    return true;
  }

  authenticateWithBiometrics(userId: string): boolean {
    throw new Error("Not implemented");
  }

  authenticateWithQRCode(qrCode: string): boolean {
    throw new Error("Not implemented");
  }
}

Problemas:

Métodos não utilizados: A classe PasswordAuthenticator implementa métodos que não fazem sentido para sua função.
Manutenção problemática: Se a interface mudar, todas as classes implementadoras precisam ser alteradas, mesmo que não utilizem os métodos novos.
Violação de responsabilidade única: As classes começam a lidar com preocupações que não deveriam ser delas.

Para resolver o problema, podemos dividir a interface Authenticator em interfaces menores e mais específicas.

Java

interface PasswordAuth {
    boolean authenticateWithPassword(String userId, String password);
}

interface BiometricAuth {
    boolean authenticateWithBiometrics(String userId);
}

interface QRCodeAuth {
    boolean authenticateWithQRCode(String qrCode);
}

class PasswordAuthenticator implements PasswordAuth {
    @Override
    public boolean authenticateWithPassword(String userId, String password) {
        System.out.println("Authenticating with password...");
        return true;
    }
}

class BiometricAuthenticator implements BiometricAuth {
    @Override
    public boolean authenticateWithBiometrics(String userId) {
        System.out.println("Authenticating with biometrics...");
        return true;
    }
}

class QRCodeAuthenticator implements QRCodeAuth {
    @Override
    public boolean authenticateWithQRCode(String qrCode) {
        System.out.println("Authenticating with QR Code...");
        return true;
    }
}

Typescript

interface PasswordAuth {
  authenticateWithPassword(userId: string, password: string): boolean;
}

interface BiometricAuth {
  authenticateWithBiometrics(userId: string): boolean;
}

interface QRCodeAuth {
  authenticateWithQRCode(qrCode: string): boolean;
}

class PasswordAuthenticator implements PasswordAuth {
  authenticateWithPassword(userId: string, password: string): boolean {
    console.log("Authenticating with password...");
    return true;
  }
}

class BiometricAuthenticator implements BiometricAuth {
  authenticateWithBiometrics(userId: string): boolean {
    console.log("Authenticating with biometrics...");
    return true;
  }
}

class QRCodeAuthenticator implements QRCodeAuth {
  authenticateWithQRCode(qrCode: string): boolean {
    console.log("Authenticating with QR Code...");
    return true;
  }
}

Benefícios da Refatoração

Interfaces específicas: Cada classe implementa apenas os métodos que realmente utiliza.
Flexibilidade: Adicionar novos métodos ou modos de autenticação não impacta implementações existentes.
Manutenção mais simples: Reduz o impacto de mudanças no código, evitando refatorações desnecessárias.

Conclusão

Princípio da Responsabilidade Única e as implicações na Orientação a Objetos e Arquitetura de Software

Victor Lima Reboredo — Tue, 03 Sep 2024 15:59:15 +0000

Introdução

O paradigma orientado a objetos é amplamente difundido no mundo de desenvolvimento de software. Através dele conseguimos simular de maneira eficiente as modularidades de um processo no mundo real, com reaproveitamento de código e aplicando métodos e padrões que tornam o código manutenível, eficiente e mais limpo e direto.

Coesão

Dentre os diversos conceitos aplicados na Orientação a Objetos, um ótimo conceito para se aprofundar é a coesão. A coesão é um princípio extremamente útil na programação (mesmo se utilizamos outro paradigma ao programar, como o estruturado, por exemplo). Através da coesão conseguimos organizar o código de maneira a deixá-lo mais limpo e esteticamente bem estruturado.

Em seu livro "Orientação a Objetos: Aprenda seus conceitos e suas aplicabilidades de forma efetiva", o professor Thiago Leite e Carvalho define coesão como um conceito que:

"[...] preconiza que cada unidade de código deve ser responsável somente por possuir informações e executar tarefas que dizem respeito somente ao conceito que ela pretende representar."

Podemos aplicar a coesão através das classes e dos relacionamentos associativos das mesmas. Criar unidades de código coesas com classes e associações contribui para definição de blocos de códigos responsáveis somente por tarefas e conceitos às quais elas se propõem. (Thiago Leite e Carvalho, pg. 23)

Classes coesas são extremamente importantes em sistemas orientados a objetos. São mais fáceis de dar manutenção, são compostas por menos códigos e podem ser mais facilmente reutilizadas no software. Elas também são menos propensas a defeitos e bugs.

Single Responsability Principle

O SRP ou também Princípio da Responsabilidade Única é o primeiro pilar do solid e existe para que possamos aplicar a coesão no nosso código.
Ele nada mais é do que a parte prática de tudo o que vimos até aqui, portanto colocamos em prática a coesão através do SRP. Ele preconiza que:

Uma classe deve ter uma, e apenas uma, razão para mudar.

É um tanto complexo no dia a dia do programador, termos bem definido um grupo de regras que irão de certa forma definir o conceito de uma classe coesa e de uma classe não-coesa. Os conceitos que podem rodear isso acabam por ser subjetivos. Acredito que o principal a se verificar em uma análise de classe é quantos métodos diferentes ela tem/quão grande elas são e quantos comportamentos diferentes é possível encontrar nela. Quanto mais métodos, código e comportamentos uma classe tiver, mais ela se tornará uma candidata ao título de "Classe não-coesa".

Exemplo

Neste exemplo, criarei a classe User. Ela será responsável por salvar um usuário em meu sistema, validar o e-mail e enviar um e-mail de boas-vindas para o usuário.

class User {
  constructor(public name: string, public email: string) {}

  saveToDatabase() {
    console.log(`Saving user ${this.name} to the database...`);
  }

  sendWelcomeEmail() {
    console.log(`Sending welcome email to ${this.email}...`);
  }

  validateEmail() {
    console.log(`Validating email ${this.email}...`);
    return this.email.includes("@");
  }
}

const user = new User("John Doe", "john.doe@example.com");

if (user.validateEmail()) {
  user.saveToDatabase();
  user.sendWelcomeEmail();
}

Nossa classe está totalmente errada! Ela tem 3 tarefas totalmente distintas a que deveriam ser independentes. Se alguma lógica de validação do e-mail ou do banco de dados mudar, teremos que modificar a classe inteira, que deveria apenas representar a entidade Usuário. Criar testes unitários para testar a classe se torna uma dor de cabeça, já que devemos ter teste para cada método com lógicas distintas.

Aplicando o SRP...

class User {
  constructor(public name: string, public email: string) {}
}

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

class EmailService {
  sendWelcomeEmail(user: User) {
    console.log(`Sending welcome email to ${user.email}...`);
  }
}

class UserValidator {
  validateEmail(user: User): boolean {
    console.log(`Validating email ${user.email}...`);
    return user.email.includes("@");
  }
}

const user = new User("John Doe", "john.doe@example.com");
const validator = new UserValidator();
const repository = new UserRepository();
const emailService = new EmailService();

if (validator.validateEmail(user)) {
  repository.save(user);
  emailService.sendWelcomeEmail(user);
}

Agora, cada classe tem uma única responsabilidade. User apenas modela a entidade, UserRepository lida com o armazenamento no banco de dados, EmailService cuida do envio de emails, e UserValidator se concentra na validação.

Desta maneira podemos modularizar melhor qualquer mudança/dependência nas validações, isto é, se a validação mudar basta mudar um local do código. Se for necessário incluir mais campos na entidade de usuário e incluir uma validação para este novo campo, toda a edição no código ficará mais fácil!

Aplicando SRP em outras frentes

Um ponto importantíssimo no mundo de Software é a arquitetura que aplicamos. Pensando nesse princípio, um padrão arquitetural que vem à minha mente é o MVC (Model - View - Controller).

Esse modelo de software segrega as responsabilidades de um software monolítico em 3 frentes:

Model: É o domínio de nossa regra de negócio. São classes que representam tabelas de banco de dados ou entidades bem definidas. Através delas podemos gerenciar repositório de dados, fazer consultas e manipular dados.
View: É a camada que define a parte de interface de usuário da aplicação. Nela estarão os elementos gráficos interativos onde o cliente irá requisitar, manipular e deletar dados. É a parte de front.
Controller: É a camada responsável por ligar o "core" do software ao cliente (usuário, seja via app mobile, desktop ou web). Ele pode capturar uma requisição - seja via REST, GraphQL, gRPC e muitos outros - e converter tudo isso em uma ação dentro da aplicação.

Existem no mercado diversos frameworks/libs que utilizam o MVC como arquitetura, os principais e mais completos - na minha opinião, é claro - são: Laravel (PHP), Express (JavaScript), ASP.Net Core MVC (C#), Spring (Java) e Django (Python).

Conclusão

O Princípio da Responsabilidade Única é muito mais do que uma regra teórica: é uma prática essencial para quem busca escrever um código orientado a objetos robusto e escalável. Ao aplicar o SRP, garantimos que nossas classes se mantenham coesas, focadas em uma única responsabilidade, o que facilita a manutenção, testes e futura evolução do sistema.

A coesão, como discutido, é um dos pilares para alcançar da boa arquitetura de software. Quando uma classe possui uma única responsabilidade, ela se torna mais fácil de entender, de modificar e de estender, permitindo que o código evolua de maneira mais natural conforme as necessidades do projeto mudam. Além disso, a aplicação do SRP reduz a chance de bugs, pois minimiza o impacto das mudanças ao isolar responsabilidades.

Adotar o SRP desde o início de um projeto pode parecer um desafio, mas os benefícios a longo prazo superam em muito o esforço inicial. Projetar classes pequenas e bem definidas contribui para a criação de um sistema modular, onde cada parte pode ser desenvolvida, testada e mantida independentemente. Isso não apenas melhora a qualidade do código, mas também promove uma maior colaboração entre equipes de desenvolvimento, permitindo que diferentes partes do sistema evoluam em paralelo sem interferências indesejadas.

Em suma, o SRP não é apenas um princípio de design, mas uma prática que influencia diretamente a qualidade e a sustentabilidade do software que desenvolvemos. Incorporá-lo em nossa abordagem à programação orientada a objetos é um passo fundamental para construir sistemas que sejam não apenas funcionais, mas também fáceis de manter e adaptar ao longo do tempo.

(L): Aplicando o "Princípio da substituição de Liskov" com Typescript e Java

Victor Lima Reboredo — Thu, 29 Aug 2024 14:56:48 +0000

Conceitos

Interfaces

Uma interface define um contrato ou um conjunto de métodos e propriedades que uma classe deve implementar. Interfaces são usadas para garantir que uma classe siga um determinado formato, mas não fornecem implementação de métodos, apenas suas assinaturas.

Sempre que uma classe implementa uma interface, ela assina todos os contratos (métodos e atributos) da interface. Cada atributo e método é obrigatoriamente implementado.

SOLID

Sobre o LSP

O "L" do acrônimo significa "Liskov Substitution Principle". A frase que o uncle bob utilizou para definir esse princípio foi:

"Classes derivadas devem ser capazes de substituir totalmente as classes-bases"

Sugere-se portanto que a classe derivada deve estar o mais próximo possível da classe-base, de modo que a classe derivada possa substituir sua classe-base sem qualquer modificação no código.

Este princípio foi introduzido por Barbara Liskov em 1988, com base na teoria de abstração de dados e tipos. Derivado do conceito de Design by Contracts (DBC), popularizado por Bertrand Meyer em 1986.

Outra especificação desse princípio é:

O subtipo deve ser utilizado como seu tipo base sem nenhuma surpresa.

Na programação, mudanças e surpresas podem causar problemas. Se uma funcionalidade do sistema precisar ser substituída, a nova deve fornecer o mesmo tipo de informação, ou o sistema pode falhar. Para garantir que a classe S tenha o mesmo comportamento que a classe base T, é essencial usar um contrato (interface ou classe abstrata) que defina os métodos obrigatórios para implementação da funcionalidade nova, de modo a garantir a integridade da similaridade entre a classe S e classe T.

Aplicação prática

Considere uma classe base Bird com um método voar() que será usado em duas classes-filhas: Sparrow e Ostrich.

Arquivo: bird.java

class Bird {
    void fly() {
        System.out.println("I can fly!");
    }
}

class Sparrow extends Bird {
    // Herda o comportamento de 'fly' da classe 'Bird'
}

class Ostrich extends Bird {
    @Override
    void fly() {
        throw new UnsupportedOperationException("I cannot fly");
    }
}

Arquivo: bird.ts

class Bird {
  fly() {
    console.log("I can fly!");
  }
}

class Sparrow extends Bird {}

class Ostrich extends Bird {
  fly() {
    throw new Error("I cannot fly");
  }
}

Problemas encontrados

Aqui, a classe Sparrow adere ao LSP porque pardais de fato podem voar. No entanto, a classe Ostrich viola o LSP porque sobrescreve o método voar() de uma forma que altera fundamentalmente seu comportamento, quebrando as expectativas definidas pela classe Bird.

Como corrigir?

Precisaremos aplicar o LSP dividindo cada especificidade das classes Sparrow e Ostrich em contratos (interfaces ou classes abstratas, aqui usarei interfaces) que eles devem assinar para modular os comportamentos de cada:

Arquivo: bird.java

interface Bird {
    String getName();
    void makeSound();
}

interface FlyingBird extends Bird {
    void fly();
}

class Sparrow implements FlyingBird {
    private String name;

    public Sparrow(String name) {
        this.name = name;
    }

    @Override
    public String getName() {
        return this.name;
    }

    @Override
    public void makeSound() {
        System.out.println("Chirp chirp!");
    }

    @Override
    public void fly() {
        System.out.println(this.name + " is flying!");
    }
}

class Ostrich implements Bird {
    private String name;

    public Ostrich(String name) {
        this.name = name;
    }

    @Override
    public String getName() {
        return this.name;
    }

    @Override
    public void makeSound() {
        System.out.println("Boom boom!");
    }
}

public class Main {
    public static void main(String[] args) {
        Sparrow sparrow = new Sparrow("Little Sparrow");
        sparrow.makeSound(); // Chirp chirp!
        sparrow.fly(); // Little Sparrow is flying!

        Ostrich ostrich = new Ostrich("Ostrich");
        ostrich.makeSound(); // Boom boom!
        ostrich.fly(); // Error: Method 'fly' does not exist on 'Ostrich'
    }
}

Arquivo: bird.ts

interface Bird {
  name: string;
  makeSound(): void;
}

interface FlyingBird extends Bird {
  fly(): void;
}

class Sparrow implements FlyingBird {
  name: string;

  constructor(name: string) {
    this.name = name;
  }

  makeSound() {
    console.log("Chirp chirp!");
  }

  fly() {
    console.log(`${this.name} is flying!`);
  }
}

class Ostrich implements Bird {
  name: string;

  constructor(name: string) {
    this.name = name;
  }

  makeSound() {
    console.log("Boom boom!");
  }
}

const sparrow = new Sparrow("Little Sparrow");
sparrow.makeSound(); // Chirp chirp!
sparrow.fly(); // Little Sparrow is flying!

const ostrich = new Ostrich("Ostrich");
ostrich.makeSound(); // Boom boom!
ostrich.fly(); // Error: Method 'fly' does not exist on 'Ostrich'

Análise

Explicação da Correção
Interface Bird: Define comportamentos comuns a todas as aves, como makeSound(). Todas as aves devem implementar essa interface.

Interface FlyingBird: Herda de Bird e adiciona o comportamento fly(), que é específico para aves que podem voar.

Classe Sparrow: Implementa a interface FlyingBird, já que pardais podem voar. Esta classe define o comportamento tanto de emitir som quanto de voar.

Classe Ostrich: Implementa apenas a interface Bird, pois avestruzes não podem voar. Essa classe não possui o método fly() e, portanto, não viola o LSP.

Conclusão

O LSP é crucial para garantir que o código seja modular, reutilizável e fácil de manter. Violações do LSP podem levar a código frágil que quebra quando novas subclasses são introduzidas ou quando subclasses existentes são modificadas, pois isso pode levar a comportamentos inesperados em partes do código que dependem da superclasse.

A substituição de subtipos permite que um módulo seja estendido sem modificação, essencial para a flexibilidade proporcionada pelo Princípio Aberto/Fechado (OCP), viabilizada pelo Princípio da Substituição de Liskov. Contratos (implementados através de interfaces ou classes abstratas) são cruciais para um design seguro, mas devem ser bem compreendidos pelos programadores, ajudando a evitar erros comuns em softwares legados. Eles também fornecem orientações valiosas sobre como implementar e utilizar o código, bastando observar o contrato em questão.

Implicações Práticas

Ao projetar subclasses, certifique-se de que elas possam ser usadas onde quer que sua superclasse seja usada, sem introduzir bugs ou exigir tratamentos especiais.
Evite criar subclasses que violem o comportamento esperado da superclasse, pois isso pode levar a problemas de manutenção e bugs inesperados.

Compreender e aplicar o Princípio da Substituição de Liskov ajuda os desenvolvedores a criar sistemas orientados a objetos mais previsíveis e estáveis.

(O): Aplicando o "Princípio do Aberto/Fechado" com Typescript e Java

Victor Lima Reboredo — Wed, 28 Aug 2024 17:54:34 +0000

Conceitos

Abstração

A Abstração nos conceitos da orientação a objeto é uma prática de definir apenas aspectos essenciais que uma classe deve possuir. As classes, devem por natureza, ser incompletas e imprecisas para que possamos modelar especificidades através de classes filhas. Assim surge o conceito de classes filhas, classes mães e herança.

Herança

Herança é a representação de relacionamento entre classes em que uma classe extende a outra de modo a herdar os comportamentos da classe mãe.

SOLID

Open/Closed Principle

O "O" do acrônimo significa "Open/Closed Principle". A frase que o uncle bob utilizou para definir esse princípio foi:

"Uma classe deve estar aberta para extensão, mas fechada para modificação"

Segundo o Princípio do Aberto/Fechado, devemos desenvolver uma aplicação garantindo que escreveremos classes ou módulos de maneira genérica de modo que sempre que sentir a necessidade de estender o comportamento da classe ou do objeto, você não precisará alterar a classe propriamente dita. Extensão aqui pode-se ler como adição ou alteração de procedimentos.

O objetivo é permitir a adição de novas funcionalidades sem a necessidade de alterar o código existente. Isso minimiza o risco de introduzir bugs e deixa o código mais manutenível.

Aplicação prática

Imagine que você tem uma classe DiscountCalculator que calcula descontos de produtos. Inicialmente, temos duas categorias de produtos: Electronics e Clothing. Vamos começar sem aplicar o OCP (Open/Closed Principle):

Java

class Product {
    private String name;
    private double price;

    public Product(String name, double price) {
        this.name = name;
        this.price = price;
    }

    public String getName() {
        return name;
    }

    public double getPrice() {
        return price;
    }
}

class DiscountCalculator {
    public double calculateDiscount(Product product) {
        if (product.getName().equals("Electronics")) {
            return product.getPrice() * 0.9; // 10% de desconto
        } else if (product.getName().equals("Clothing")) {
            return product.getPrice() * 0.8; // 20% de desconto
        }
        return product.getPrice();
    }
}

public class Main {
    public static void main(String[] args) {
        Product electronics = new Product("Electronics", 100);
        Product clothing = new Product("Clothing", 50);

        DiscountCalculator calculator = new DiscountCalculator();

        System.out.println(calculator.calculateDiscount(electronics)); // 90
        System.out.println(calculator.calculateDiscount(clothing)); // 40
    }
}

Typescript

class Product {
    private _name: string;
    private _price: number;

    constructor(name: string, price: number) {
        this._name = name;
        this._price = price;
    }

    public get name() { return this.name };

    public set name(value: string) { this.name = value };

    public get price() { return this.price };

    public set price(value: number) { this.price = value };
}

class DiscountCalculator {
    public calculateDiscount(product: Product): number {
        if (product.name === 'Electronics') {
            return product.price * 0.9; // 10% de desconto
        } else if (product.name === 'Clothing') {
            return product.price * 0.8; // 20% de desconto
        }
        return product.price;
    }
}

const electronics = new Product('Electronics', 100);
const clothing = new Product('Clothing', 50);

const calculator = new DiscountCalculator();

console.log(calculator.calculateDiscount(electronics)); // 90
console.log(calculator.calculateDiscount(clothing)); // 40

Problemas ao Não Aplicar o OCP

Violação do encapsulamento: Toda vez que um novo tipo de produto precisar de um desconto diferente, será necessário modificar o método calculateDiscount, incluindo uma nova condicional no if.

Dificuldade em manutenção: Se o método crescer com muitos if/else ou switch, ele se tornará difícil de manter e testar.

Risco de introdução de erros: Alterações no método podem introduzir bugs em outras partes do código que dependem desse método.

Como corrigir?

Agora, vamos aplicar o Open/Closed Principle refatorando o código para permitir a adição de novos tipos de descontos sem modificar o código existente.

Java

class Product {
    private String name;
    private double price;

    public Product(String name, double price) {
        this.name = name;
        this.price = price;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public double getPrice() {
        return price;
    }

    public void setPrice(double price) {
        this.price = price;
    }
}

interface DiscountStrategy {
    double calculate(Product product);
}

class ElectronicsDiscount implements DiscountStrategy {
    @Override
    public double calculate(Product product) {
        return product.getPrice() * 0.9; // 10% de desconto
    }
}

class ClothingDiscount implements DiscountStrategy {
    @Override
    public double calculate(Product product) {
        return product.getPrice() * 0.8; // 20% de desconto
    }
}

class NoDiscount implements DiscountStrategy {
    @Override
    public double calculate(Product product) {
        return product.getPrice();
    }
}

class DiscountCalculator {
    private DiscountStrategy discountStrategy;

    public DiscountCalculator(DiscountStrategy discountStrategy) {
        this.discountStrategy = discountStrategy;
    }

    public double calculateDiscount(Product product) {
        return discountStrategy.calculate(product);
    }
}

public class Main {
    public static void main(String[] args) {
        Product electronics = new Product("Electronics", 100);
        Product clothing = new Product("Clothing", 50);
        Product books = new Product("Books", 30);

        DiscountCalculator electronicsDiscount = new DiscountCalculator(new ElectronicsDiscount());
        DiscountCalculator clothingDiscount = new DiscountCalculator(new ClothingDiscount());
        DiscountCalculator booksDiscount = new DiscountCalculator(new NoDiscount());

        System.out.println(electronicsDiscount.calculateDiscount(electronics)); // 90
        System.out.println(clothingDiscount.calculateDiscount(clothing)); // 40
        System.out.println(booksDiscount.calculateDiscount(books)); // 30
    }
}

Typescript

class Product {
    private _name: string;
    private _price: number;

    constructor(name: string, price: number) {
        this._name = name;
        this._price = price;
    }

    public get name() { return this.name };

    public set name(value: string) { this.name = value };

    public get price() { return this.price };

    public set price(value: number) { this.price = value };
}

interface DiscountStrategy {
    calculate(product: Product): number;
}

class ElectronicsDiscount implements DiscountStrategy {
    calculate(product: Product): number {
        return product.price * 0.9; // 10% de desconto
    }
}

class ClothingDiscount implements DiscountStrategy {
    calculate(product: Product): number {
        return product.price * 0.8; // 20% de desconto
    }
}

class NoDiscount implements DiscountStrategy {
    calculate(product: Product): number {
        return product.price;
    }
}

class DiscountCalculator {
    private discountStrategy: DiscountStrategy;

    constructor(discountStrategy: DiscountStrategy) {
        this.discountStrategy = discountStrategy;
    }

    public calculateDiscount(product: Product): number {
        return this.discountStrategy.calculate(product);
    }
}

const electronics = new Product('Electronics', 100);
const clothing = new Product('Clothing', 50);
const books = new Product('Books', 30);

const electronicsDiscount = new DiscountCalculator(new ElectronicsDiscount());
const clothingDiscount = new DiscountCalculator(new ClothingDiscount());
const booksDiscount = new DiscountCalculator(new NoDiscount());

console.log(electronicsDiscount.calculateDiscount(electronics)); // 90
console.log(clothingDiscount.calculateDiscount(clothing)); // 40
console.log(booksDiscount.calculateDiscount(books)); // 30

Conclusão

Aplicar o Princípio do Aberto/Fechado é imprescindível se precisamos adicionar novos recursos ou comportamentos sem ter a necessidade de modificar tão profundamente a base de código existente. Na verdade, com o tempo, vemos que é praticamente impossível evitar 100% a mudança da base do código porém é possível sim mitigar a quantidade bruta de código a ser alterado para inserção de uma nova funcionalidade.

Esse princípio torna o código mais adaptável a mudanças, seja para atender novos requisitos ou corrigir erros.

(S): Aplicando o "Princípio da Responsabilidade Única" com Typescript e Java

Victor Lima Reboredo — Sun, 18 Aug 2024 21:54:19 +0000

Conceitos

O "S" do acrônimo significa "Single Responsibility Principle". A frase que o uncle bob utilizou para definir esse princípio foi:

"Uma classe deve ter uma, e apenas uma, razão para mudar."

Segundo o Princípio da Responsabilidade Única, quando desenvolvemos nossas classes, precisamos ter em mente muito bem sua funcionalidade em particular. Se uma classe trata de duas funcionalidades a melhor coisa a fazer é dividi-la.
Ao aprender programação orientada a objetos, é comum atribuir múltiplas responsabilidades a uma única classe, criando as chamadas God Classes. Embora inicialmente pareça eficiente, essa abordagem mistura responsabilidades, tornando difícil alterar uma delas sem impactar as outras.

Aplicação prática

Para exemplificar uma aplicação prática desse problema criarei uma classe chamada UserService. Ela vai manipular diversas necessidades relacionados aos usuários.

Primeiro, vejamos a aplicação dessa classe sem utilizar o Princípio da Responsabilidade Única. Aqui nossa classe faz várias coisas: manipula dados do usuário, valida esses dados, e cria usuários no banco de dados.

Java

import java.util.ArrayList;
import java.util.List;

class User {
    private int id;
    private String name;
    private String email;

    public User(int id, String name, String email) {
        this.id = id;
        this.name = name;
        this.email = email;
    }

    @Override
    public String toString() {
        return "User{id=" + id + ", name='" + name + "', email='" + email + "'}";
    }
}

class UserService {
    private List<User> users = new ArrayList<>();

    public void addUser(String name, String email) {
        if (this.validateEmail(email)) {
            User newUser = new User(users.size() + 1, name, email);
            users.add(newUser);
            saveToDatabase(newUser);
        } else {
            throw new IllegalArgumentException("E-mail inválido");
        }
    }

    private boolean validateEmail(String email) {
        return email.matches("\\S+@\\S+\\.\\S+");
    }

    private void saveToDatabase(User user) {
        System.out.println("Salvando usuário no banco de dados " + user);
    }

    public List<User> getUsers() {
        return users;
    }

    public static void main(String[] args) {
        UserService userService = new UserService();
        userService.addUser("John Doe", "john@example.com");
        System.out.println(userService.getUsers());
    }
}

Typescript

type User = { id: number, name: string, email: string }

class UserService {
    private users: User[] = [];

    addUser(name: string, email: string) {
        if (this.validateEmail(email)) {
            const newUser = {
                id: this.users.length + 1,
                name: name,
                email: email
            };
            this.users.push(newUser);
            this.saveToDatabase(newUser);
        } else {
            throw new Error("E-mail inválido");
        }
    }

    private validateEmail(email: string): boolean {
        const emailRegex = /\S+@\S+\.\S+/;
        return emailRegex.test(email);
    }

    private saveToDatabase(user: User) {
        console.log("Salvando usuário no banco de dados", user);
    }

    getUsers() {
        return this.users;
    }
}

O principal problema que podemos encontrar aqui é a manutenção no código. Se houver uma mudança na lógica de validação ou na forma como os dados são salvos, isso afetará diretamente essa classe, dificultando a manutenção.

Agora, como podemos solucionar isso?
Devemos segregar nossa lógica contida na God Class "UserService" em diversas classes com funcionalidades bem definidas. Vejamos:

Java

import java.util.ArrayList;
import java.util.List;

// validador
class EmailValidator {
    public boolean validate(String email) {
        return email.matches("\\S+@\\S+\\.\\S+");
    }
}

// Repositório que manipula os dados no banco de dados
class UserRepository {
    private List<User> users = new ArrayList<>();

    public void save(User user) {
        System.out.println("Salvando usuário no banco de dados " + user);
        users.add(user);
    }

    public List<User> getAll() {
        return users;
    }
}

// Aplicamos as regras do domain com injeção de dependências
class UserService {
    private EmailValidator emailValidator;
    private UserRepository userRepository;

    public UserService(EmailValidator emailValidator, UserRepository userRepository) {
        this.emailValidator = emailValidator;
        this.userRepository = userRepository;
    }

    public void addUser(String name, String email) {
        if (emailValidator.validate(email)) {
            User newUser = new User(userRepository.getAll().size() + 1, name, email);
            userRepository.save(newUser);
        } else {
            throw new IllegalArgumentException("E-mail inválido");
        }
    }

    public List<User> getUsers() {
        return userRepository.getAll();
    }
}

Typescript

// validador
class EmailValidator {
    validate(email: string): boolean {
        const emailRegex = /\S+@\S+\.\S+/;
        return emailRegex.test(email);
    }
}

// Repositório que manipula os dados no banco de dados
class UserRepository {
    private users: { id: number, name: string, email: string }[] = [];

    save(user: { id: number, name: string, email: string }) {
        console.log("Salvando usuário no banco de dados", user);
        this.users.push(user);
    }
    getAll() {
        return this.users;
    }
}

// Aplicamos as regras do domain com injeção de dependências
class UserService {
    constructor(
        private emailValidator: EmailValidator,
        private userRepository: UserRepository
    ) {}

    addUser(name: string, email: string) {
        if (this.emailValidator.validate(email)) {
            const newUser = {
                id: this.userRepository.getAll().length + 1,
                name: name,
                email: email
            };
            this.userRepository.save(newUser);
        } else {
            throw new Error("E-mail inválido");
        }
    }

    getUsers() {
        return this.userRepository.getAll();
    }
}

Aplicar o Princípio da Responsabilidade Única (Single Responsibility Principle) é crucial para a criação de software robusto e escalável. Ao garantir que cada classe tenha apenas uma responsabilidade, reduzimos a complexidade do código, facilitamos sua manutenção e refatoração, e minimizamos o risco de erros. Esse princípio é fundamental para manter a qualidade e a longevidade do projeto, promovendo um design mais limpo e eficiente.