Princípio da segregação de interface

Origem: Wikipédia, a enciclopédia livre.

No campo da engenharia de software, o princípio da segregação de Interface (ISP) afirma que nenhum cliente deve ser forçados a depender de métodos que não utiliza.[1] ISP divide interfaces que são muito grandes em menores e mais específicas, para que os clientes só necessitem saber sobre os métodos que são de interesse para eles. Tais interfaces encolhidas são também chamados de papel de interfaces.[2] ISP destina-se a manter um sistema desacoplado e, assim, mais fácil para reestruturar, modificar. O ISP é um dos cinco princípios do SOLID de design orientado a objeto, semelhante ao Princípio de Alto Coesão do GRASP.[3]

Importância no design orientado a objeto[editar | editar código-fonte]

Dentro design orientado a objeto, interfaces fornecem camadas de abstração que facilitam a explicação conceitual do código e cria uma barreira que impede o acoplamento por dependências.

De acordo com muitos especialistas em software que assinaram o Manifesto para Software Artesanal , escrevendo sofware bem trabalhado e auto-explicativo é quase tão importante quanto escrever software funcional.[4] Usando interfaces para descrever a intenção do software é muitas vezes uma boa idéia.

Um sistema pode tornar-se tão acoplado em vários níveis, que não é mais possível fazer uma alteração em um lugar sem a necessidade de muitas alterações adicionais.[1] Usando uma interface ou uma classe abstrata pode evitar este efeito colateral.

Origem[editar | editar código-fonte]

O ISP foi usado pela primeira vez e formulado por Robert C. Martin , enquanto realizava consultoria para Xerox. Xerox havia criado um novo sistema de impressora que podia executar uma variedade de tarefas, tais como grampeamento e envio de fax. O software para este sistema foi criado a partir do zero. Com o crescimento do software, fazer modificações, tornou-se mais e mais difícil, de modo que mesmo a menor mudança levaria um ciclo de desenvolvimento de uma hora, o que fez o desenvolvimento quase impossível.

O problema de design foi que uma única classe Trabalhadora foi usado por quase todas as tarefas. Sempre que um trabalho de impressão ou de um grampeamento era necessário, era feito uma chamada para aquela classe. Isto resultou em uma classe com multidões de métodos específicos para uma variedade de diferentes clientes. Devido a esta estrutura, uma tarefa de grampear saberia todos os métodos da impresora, embora não houvesse necessidade deles.

A solução sugerida por Martin, atualmente conhecida como Princípio da Segregação de Interface. Aplicado no software da Xerox, uma camada de interface foi adicionada entre a classe Trabalhadora e seus clientes usando Princípio da Inversão de Dependência. Em vez de ter uma grande classe Trabalhadora, era criado uma interface para a tarefa de grampear ou para impressão, que seria usado pela classe de Grampos ou de Impressão, respectivamente, chamando os métodos da classe Trabalhadora. Portanto, uma interface foi criada para cada tipo de trabalho, que foi implementado pela classe Trabalhadora.

Típica violação[editar | editar código-fonte]

Uma típica violação do Princípio da Segregação de Interface é dado no Desenvolvimento Ágil de Software: Princípios, Padrões e Práticas[1] no exemplo "Transações de ATM" e, em um artigo, também escrito por Robert C. Martin , especificamente, sobre o ISP.[5] Este exemplo descreve a Interface de Usuário de um caixa eletrônico, que processa todos os pedidos, como um pedido de depósito, ou um pedido de resgate, e como esta interface precisa ser segregada em interfaces individuais e mais específicas.

Ver também[editar | editar código-fonte]

  • SOLID – o "I" em SOLID, significa Princípio da Segregação de Interface

Referências[editar | editar código-fonte]

Ligações externas[editar | editar código-fonte]