Nesse artigo vamos ver a teoria por trás do Princípio da Segregação de Interface (Interface Segregation Principle), ou simplesmente ISP, e como representar esse conceito em aplicações JavaScript.
Sua definição formal diz:
Uma classe não deve ser forçada a implementar métodos que não irá usar.
Exemplo de violação
Abaixo temos um exemplo que viola o ISP:
A interface ISmartDevice define os métodos print e scan, e a classe Printer a implementa, dessa forma, toda classe que herdar de Printer deve implementar os dois métodos.
Simples, não? O problema é que a classe Economic **deve ter apenas o método print e dessa forma forçamos a implementação do método scan, violando o ISP**.
Resolvendo a violação do ISP
Aqui temos um exemplo onde aplicamos o ISP, dividindo ISmartDevice em duas interfaces menores: IPrinter, e IScanner. Desta forma, temos um código mais desacoplado e fácil de manter, podendo implementar classes que não precisam de todas as funcionalidades.
Até aí tudo bem, mas como vamos implementar isso em JavaScript se a linguagem não suporta interfaces? Vamos parar um pouco para pensar, o que é uma interface?
Interface é um contrato que força uma classe ou um objeto (no caso do JavaScript) a implementar uma funcionalidade especifica.
E na prática, como funciona?
Realmente não existe uma implementação concreta de interfaces em JavaScript, mas isso não nos impede de criar um “contrato” que se comporte dessa maneira. Vejamos o seguinte código:
class Printer {
constructor(name) {
this.name = name;
}
}
class AllInOne extends Printer {
constructor(name) {
super(name);
}
scan() {
return 'scanning...';
}
}
function printerFunctionalities(printers) {
console.log('Impressoras digitalizando: ');
for (let printer of printers) {
console.log(`${printer.name} is ${printer.scan()}`);
}
}
let printers = [
new AllInOne('HP 1'),
new AllInOne('HP 2'),
];
printerFunctionalities(printers);
Aqui temos uma classe Printer e uma subclasse AllInOne que implementa o método scan. Temos também uma função chamada printerFunctionalities que percorre uma lista de instâncias de AllInOne ****chamando o método scan de cada um dos itens da lista.
Mas temos um problema, e se criarmos uma classe Economic que não deve ter o método scan?
class Economic extends Printer {
constructor(name) {
super(name);
}
}
Se adicionarmos uma instância de Economic dentro do array o código retornará um erro, e é óbvio que é porque não implementamos o método scan dentro da classe Economic.
let printers = [
new AllInOne('HP 1'),
new AllInOne('HP 2'),
new Economic('HP 3'),
];
De fato, JavaScript não tem uma implementação de interfaces, mas nesse código criamos um “contrato” que nos força a implementar o método scan.
Poderíamos acabar com esse erro implementando o método scan na classe Economic, mas não é isso que queremos, pois desta forma estaríamos violando o ISP. Então, para resolver esse problema de uma maneira simples que nos trará o resultado esperado. Vamos adicionar uma condição que verifica a existência do método em cada uma das instâncias.
function printerFunctionalities(printers) {
console.log('Impressoras digitalizando: ');
for (let printer of printers) {
if (printer.scan) {
console.log(`${printer.name} is ${printer.scan()}`);
}
}
}
Dessa forma tornamos o método scan opcional, não forçando classes concretas a implementarem métodos desnecessários, evitamos um aumento no acoplamento e deixamos nossas classes mais coesas.
Conclusão
O fato de JavaScript não possuir interfaces faz com que esse princípio não se aplique estritamente como os outros. Entretanto, é importante lembrar que interfaces são “contratos” e podemos implementá-los de forma implícita em JavaScript.
Espero que estejam gostando da série, se tiverem dúvidas ou sugestões não deixem de comentar. Abraço!