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
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.
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.
Top comments (0)