Se você programa em alguma linguagem de programação orientada a objeto, com certeza conhece os termos “Private”, “protected” e “public” e muito provavelmente sabe para que eles servem. Métodos ou membros públicos são aqueles que podem ser acessados por outras classes, os protegidos apenas pelos descendentes e os privados só possuem visibilidade local, ou seja, dentro da própria classe. Parece simples, porém, é muito comum encontrar programadores que parecem não seguir critério algum ao definir o nível de visibilidade dos membros de suas classes, ou então aplicam alguma metodologia aleatória para este fim. Propriedades que eram protegidas são publicadas durante o desenvolvimento de outras classes clientes, conforme a necessidade. Classes “amigáveis” (class friendly) são criadas para permitir acesso a funções protegidas. Práticas como essas acabam por criar uma arquitetura extremamente confusa, com componentes de difícil entendimento, difíceis de serem testados e expandidos. Qual seria então o melhor critério para evitar esse tipo de problema?

Ao desenhar uma classe devemos ter uma ideia bem clara de qual a responsabilidade dela, caso contrário, coloque em dúvida a necessidade de criá-la. O raciocínio é simples: se não sabemos o que a classe deve fazer, então não precisamos dela. Após a definição clara de qual é a responsabilidade da classe, levando em consideração a coesão e nível de acoplamento desejado, devemos pensar sobre a sua interface. Para entender melhor, basta imaginar como a classe deve ser vista por suas classes clientes, ou seja, as classes ou componentes que irão utilizá-las. Apenas métodos e propriedades que permitam acesso e manipulação de dados relacionados à responsabilidade da classe devem ser públicos. Você deve fazer isso não para impedir que outros acessem dados internos de suas classes, mas, principalmente, para garantir que elas sejam mais legíveis, inteligíveis e fáceis de usar. O ideal é que qualquer programador do mundo possa, apenas lendo os métodos públicos de sua classe, dizer qual a responsabilidade dela, e quais métodos chamar, e como chamá-los para conseguir usufruir de suas funcionalidades. Se você não se preocupar em publicar apenas o que for necessário, sua classe corre o risco de ficar confusa demais e difícil de utilizar.

Uma analogia com o mundo real pode ajudá-lo a entender melhor esse raciocínio: imagine um carro onde, junto com os pedais de freio e embreagem, tivessem outros controles estranhos, como um pedal pra regular o nível do óleo e outro para ativar e controlar a bomba de gasolina. Esse carro faria com que o condutor ficasse bem confuso, e tentasse regular o consumo de gasolina manualmente enquanto dirige (um absurdo, não?).

Voltando ao mundo dos bits, por exemplo, se sua classe possuir uma coleção de itens, seria bom deixar claro se ela é dona deles e apenas ela deve poder removê-los ou incluí-los em seu container. Para isso, não disponibilize em sua interface métodos que dão acesso direto a lista, procurando sempre usar o encapsulamento onde for necessário e disponibilizando um iterador.

Se ela exigir passagem de parâmetros de inicialização, providencie construtores personalizados, onde a classe cliente possa passar os parâmetros necessários. Esse tipo de design facilita a leitura e entendimento de quem a for utilizar.

Tenha sempre esse conceito em mente: as classes clientes visualizam apenas os métodos publicados, e devem – apenas se baseando no que enxergam – entender a responsabilidade e como usar os recursos da classe servidora. Algumas ferramentas muito importantes, como o TDD (desenvolvimento orientado a testes) são extremamente eficazes e – se usadas corretamente – funcionam automaticamente como guias forçando o desenvolvedor a escrever uma interface simples e fácil de usar. Pretendo escrever um artigo sobre esse tema relacionado ao TDD em breve. Até lá.

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.