Programe para uma interface, não para uma implementação

Um conceito simples, mas nem sempre bem entendido e aplicado. ‘Programar para uma interface e não para uma implementação’, você sabe o que isto significa?
Apesar deste conceito ser aplicável a projetos de software, é mais antigo que ele, e é utilizado bem antes do primeiro compilador ser desenvolvido. Um exemplo bem obvio do que é isto, pode ser encontrado na casa de qualquer pessoa: um interruptor de luz. ‘Como assim José?’.

Um interruptor de luz é um exemplo muito bom. Consiste em um botão, que liga e desliga a luz. Uma interface simples, que esconde os detalhes de implementação de quem vai utilizá-la. Para ligar a luz, basta apertar o botão, e para desligá-la, adivinhem? Aperte novamente. A implementação está bem encapsulada – o usuário não precisa entender nada de pólo positivo, neutro, 127v, amperagem ou resistência. Qual foi o pensamento do designer ao projetar um interruptor de luz? Com certeza foi algo parecido com: ‘qual o mínimo possível de informação o usuário do meu produto precisa para usá-lo?’.
Falando em programação de software, podemos aplicar este conceito a vários pontos. Quando estamos codificando, ao criar uma nova classe, devemos sempre nos fazer a mesma pergunta que o designer do interruptor de luz fez: ‘quais operações e atributos eu devo tornar públicos para que o usuário possa usá-la de forma simples?’ e a cada nova implementação: ‘será que eu preciso expor estes parâmetros? E esse novo atributo?’. Classes com menos operações e atributos públicos, geralmente são mais simples de serem utilizadas. Lembre-se sempre: outros programadores terão que interagir com as classes e bibliotecas que você desenvolveu. Mantenha a simplicidade e procure ser objetivo.
Ao criar uma nova tela de cadastro, analogamente: ‘quais controles o usuário vai precisar para executar as operações a qual a janela se destina?’. Um erro muito comum cometido por projetistas de interfaces gráficas é transmitir a forma de funcionamento interno do algoritmo para o usuário. O clássico exemplo são as telas de cadastro. Todo mundo desenvolve, ou já desenvolveu, uma tela com os famosos botões novo, editar, cancelar, excluir e salvar, pois é a forma como o seu algoritmo funciona, e fica mais fácil publicar essa característica para o usuário. Mas, será que o usuário realmente precisa de um botão ‘editar’ quando ele quer editar um registro? Não seria mais fácil o seu sistema detectar que alguém está tentando alterar um registro e simplesmente entrar em modo de edição, como funciona, por exemplo, um editor de texto? Um botão a menos na tela, na maioria das vezes, pode significar uma interface mais simples – que é o sonho de todo usuário.
Poderia citar dezenas de exemplo aqui, mas a idéia não muda. Um carro com câmbio automático é muito melhor do que um no qual você precisa apertar a embreagem para trocar de marcha. E ambos funcionam, só que o primeiro é mais simples.
É lógico que, ao começar a pensar dessa forma, o programador vai sentir necessidade de amparo por algumas técnicas que ele pode ainda não dominar – técnicas que serão abordadas por aqui – como padrões de projetos ou Grasp. Um caminho que provavelmente não terá volta, e fará de você um melhor projetista de software.

fonte: www.olharcritico.com