Princípio da Segregação de Interface

O princípio da segregação de interfaces ajuda a resolver o problema das interfaces “gordas”, que são classes cuja interface não possui coesão com o modelo tornado as interfaces poluídas e disponibilizando métodos desnecessariamente ao cliente.

Os clientes não devem ser forçados a depender de métodos que eles não utilizam, ou seja, quando um cliente 1 depende de uma classe que contém métodos que o mesmo não utiliza, porém o cliente 2 os utiliza, o cliente 1 será afetado pelas mudanças que o cliente 2 necessite fazer na classe. Para evitar este tipo de acoplamento é que devemos separar as interfaces.

Como exemplo, considere as interfaces de um terminal de auto atendimento bancário. A interface do usuário deve ser bem flexível, possibilitando que a saída seja feita de diversas formas como na tela do equipamento ou falada por um sintetizador de voz. Para esta parte, a flexibilidade pode ser obtida através de um classe abstrata que possui todos os métodos necessários para que os dados sejam apresentados pela interface.

Consideremos também que cada transação efetuada no terminal é derivada de uma classe chamada “Transação”, logo possuímos as classes “Deposito”, “Saque” e “Transferencia”. Cada classe deve utilizar os métodos da interface com o usuário. 

A princípio possuímos um modelo como demonstra a ilustração 1.

Ilustração 1 – Hierarquia da Transação

Ao analisar melhor o modelo da ilustração 1 observamos que cada transação está sendo forçada a depender de métodos não interessantes às mesmas. Nesta situação, se alguma transação for modificada, todas as outras transações serão afetadas além das classes que dependem da interface IU. O pior acontecerá ao tentar reutilizar estas classes, pois é necessário levar junto muita coisa que não interessa. Tudo isto exala odores como rigidez, fragilidade e viscosidade.

Esses problemas observados podem ser evitados segregando a interface IU em partes individuais como “IUDeposito”, “IUSaque” e “IUTransferencia” como demonstra a ilustração 2.

Ilustração 2 – Interface IU segregada

Portanto os clientes devem depender apenas dos métodos que eles irão utilizar. Este objetivo pode ser alcançado quebrando a interface da classe poluída em interfaces específicas. Com isso é quebrado a dependência dos clientes de métodos que eles não utilizam criando uma independência mútua entre os clientes.