O que é Information hiding ?

Continuando o assunto do post O que é Design Modular? podemos fazer a seguinte pergunta: Qual técnica podemos então aplicar para desenhar e escrever bons módulos ? Vamos falar sobre Information hiding.

Information hiding é uma técnica descrita inicialmente por David Parnas e que consiste em ocultar pequenos pedaços de conhecimento do código, em outras palavras, encapsular os detalhes da implementação de componentes de software evitando que as decisões de design do módulo sejam expostas para o mundo externo. Isso permite controlar o acesso à implementação e às informações do módulo, diminuindo complexidades em sua interface e o acoplamento com o resto do sistema.

Aplicar essa técnica esconde detalhes desncessários para um usuário de um módulo. Aqui vai alguns exemplos de informações que podem ser escondidas:

• Como realizar parse de documentos JSON
• Como gerenciar threads em algum processamento
• Como armazenar informações em uma estrutura de dados

Percebe-se que a questão é “como” ? Não importa como um módulo faz determinado trabalho mas sim o que ele faz, do ponto de vista do usuário.

Variáveis privadas não são o mesmo que Information Hiding

Declarar variáveis como privadas pode ajudar no mais baixo nível a evitar um aumento do acoplamento e dependências de um sistema. Ou seja, pode contribuir para aplicar a técnica mas não garante por si só. Por exemplo, se essa mesma variável declarada como privada é acessível via métodos getters e setters esse atributo se comporta como uma variável pública.

A forma mais adequada é racionalizar quais informações fazem sentido serem compartilhadas e quais não. No exemplo anterior, a classe Conta permite o saldo ser alterado externamente, por meio do método setSaldo.

Pode fazer sentido considerar retornar o saldo, mas alterá-lo não deve ser uma função que possa ser realizada por um usuário dessa classe. Numa interpretação básica poderíamos dizer que o saldo é resultado de operações de débito e crédito numa conta, então:

Dessa forma começamos a ter uma interface mais bem elaborada com o usuário. Ele pode chamar métodos para creditar e debitar valores de uma conta, mas não alterar diretamente o saldo.

Para exemplificar, ainda podem existir informações que não fazem sentido algum nem por meio de métodos ou funções serem acessadas. Poderíamos pensar em dados que de fato só interessam a conta, por exemplo.

Adicionamos um campo de data de criação da conta. Essa informação é histórica, não faz sentido algum ser alterada ou seja, não possui motivo para um método setter. No máximo, por exemplo, um método para retornar essa data ou mesmo a idade da conta em alguma unidade (meses, dias, anos).

Conclusão

Enfim, é importante avaliar e separar bem o que faz sentido ser exposto e o que não de informações de um componente, seja uma classe, API, biblioteca ou claro um módulo. Para aplicar a técnica de Information Hiding lembre-se constantemente de avaliar quais dados e comportamentos estão sendo compartilhados bem como se a lógica da implementação também não está visível para as fronteiras do módulo (suas interfaces).

Um bom módulo é aquele com interfaces bem definidas deixando os detalhes de sua implementação por baixo dos panos.