Entendendo o Encapsulamento em Java

Com mais de 50 anos de história e muitos anos de maturidade, a orientação a objetos (OO) é um eficiente paradigma de programação. Código orientado a objetos tende a ser legível, claro, flexível quanto a mudanças e de fácil manutenção.

Apesar de ser uma eficiente solução, nem sempre ela é bem compreendida e aplicada. É comum encontrar getters e setters que violam encapsulamento e classes com excesso de responsabilidades. Quando um código aparentemente orientado a objetos não apresenta os benefícios esperados, é possível que os conceitos fundamentais tenham sido deixados de lado.

Este artigo parte de um conhecimento básico prévio do assunto e trata de um dos principais fundamentos da OO: o encapsulamento. São discutidos caminhos para o desenvolvimento de soluções verdadeiramente orientadas a objetos, que cumpram as metas de flexibilidade, clareza, legibilidade e manutenibilidade.

A programação orientada a objetos (POO) é familiar para muitos desenvolvedores da atualidade. Das linguagens de programação mais comuns hoje, grande parte oferece recursos desse paradigma. Algumas delas já são orientadas a objetos desde sua concepção, como Java, C# e Ruby.

Outras foram criadas como extensões de linguagens procedurais; é o caso de Objective-C, C++ e Object Pascal (usada no Delphi). Há aquelas que nasceram procedurais e, após alguns anos, passaram a oferecer OO como uma das alternativas de desenvolvimento, notadamente PHP.

Há, ainda, as que propõem uma orientação a objetos de maneira não tradicional, como Lua e JavaScript. Não importando qual for a linguagem usada, muitos desenvolvedores já estão acostumados a trabalhar com classes, objetos e métodos, além de sobrecarga, herança e polimorfismo.

Historicamente, o conceito de objetos como é conhecido hoje data do fim da década de 50 e início da década de 60. Na mesma época, também estava nascendo outra importante contribuição: a interface gráfica. Essas duas inovações, desde o início, caminharam juntas e impulsionaram o crescimento uma da outra.

Uma das tecnologias que mais ajudou a popularizá-las foi a linguagem de programação Smalltalk. Idealizada e desenvolvida por Alan Kay e sua equipe, na Xerox PARC, Smalltalk é uma linguagem puramente orientada a objetos, que foi publicada em 1980.

Ela foi responsável por levar a POO a conhecimento geral dos desenvolvedores. Tornou-se a primeira linguagem OO bem conhecida e influenciou praticamente todas as subsequentes (como C++, Java e C#). Além disso, impulsionou o desenvolvimento das interfaces gráficas e de muitos dos padrões de projeto conhecidos hoje, como o MVC (Model-View-Controller).

Assim, pode-se ter uma dimensão da importância dessa linguagem para o desenvolvimento da computação.

Mudança de paradigma

A POO surgiu como alternativa ao paradigma de programação procedural. Quando se fala desse paradigma, costuma-se tomar como referência a linguagem C. Pelo olhar dessa linguagem, um sistema é, essencialmente, um conjunto de funções que realizam tarefas em cima de estruturas de dados.

O foco está na sequência de passos a serem seguidos para se resolver um problema. Por exemplo: faça esta conta, peça esta entrada ao usuário, concatene estas duas strings, mostre esta informação na tela e assim por diante. Conceitualmente, um dos problemas desse paradigma é que ele está distante da maneira como os seres humanos enxergam o mundo.

Modelar os requisitos de um sistema pensando somente em funções e estruturas de dados pode ser uma tarefa difícil.

Outro problema típico desse paradigma é o uso extenso de variáveis globais, o que dificulta a manutenção e o reuso de código. Uma linguagem procedural normalmente induz o desenvolvedor a criar variáveis globais e compartilhar estado do sistema entre diferentes procedimentos e funções.

Dessa maneira, existirão pontos diferentes do código acessando e modificando os mesmos dados, já que eles são compartilhados. Isso acaba gerando um efeito indesejado: o alto acoplamento. Ao fazer uma modificação em uma parte do sistema, também é alterado o comportamento de outra parte. Isso pode introduzir falhas no sistema, caso o desenvolvedor não tenha conhecimento dos impactos de suas alterações.

Se tiver c ...