Como vimos anteriormente, durante o processo de abstração determinamos quais serão os atributos e métodos do nosso objeto. No entanto, esses métodos precisam de uma proteção, para que não sejam acessados por qualquer outro objeto diretamente. É preciso que haja um controle sobre o acesso a essas propriedades (as variáveis da instância) e esse é o papel do encapsulamento. Ele irá proteger os campos contra alterações acidentais e só permitirá que seus valores sejam modificados através de métodos específicos para isso. Esse controle é feito através de palavras reservadas chamadas modificadores de acesso. São elas: public, private, protected e internal.

Basicamente o papel de cada modificador de acesso é:

- Public : permite o acesso por qualquer outro objeto, ou seja, é a forma menos segura possível.

- Private : permite o acesso somente de dentro da mesma classe onde foi criado.

- Protected : só permitirá o acesso na classe onde ele foi criado (como o modificador Private), mas permite também o acesso a classes-filha, ou seja, que herdam dessa classe. Não se preocupem com o conceito de herança agora. Falaremos dele mais adiante. Por enquanto apenas guardem que o modificador Protected não permite acessos externos, a menos que sejam de classes derivadas dele.

- Internal : permite o acesso somente dentro do projeto atual.

Vamos aproveitar a classe Carro que criamos anteriormente para demonstrar o funcionamento do encapsulamento e dos principais modificadores de acesso. Nossa classe está dessa forma:

Nós possuímos os métodos setCor e getCor, ambos com o modificador de acesso public, ou seja, eles podem ser acessados livremente, que é o que de fato já testamos quando inserimos as cores "Azul" e "Vermelha" em nossos objetos no tutorial sobre instâncias. O IntelliSense do Visual Studio nos mostrava ambos como disponíveis quando criávamos o objeto objCarro, do tipo Carro, conforme a figura abaixo:

Isso só acontece porque eles estão com modificador public. Vamos alterar o modificador do método getCor para private e ver o que acontece. Nosso código ficará assim:

namespace WindowsFormsApplication1
        {
            internal class Carro
        
        {
            string sCor;
            string sMarca;
        
            public void setCor(string cor)
            {
                sCor = cor;
            }
        
            private string getCor()
            {
                return sCor;
            }
        }
        }
        

Agora vamos chamar o IntelliSense do Visual Studio novamente, vejam:

O setCor, que está definido como public, continua disponível, mas o getCor, que alteramos para private, não pode mais ser acessado de fora da classe Carro. Percebam o quanto isso é importante para a segurança do tráfego de dados. Nesse exemplo estamos lidando com métodos simples e inofensivos, que somente inserem e fazem a leitura de uma propriedade em um objeto, mas poderíamos ter, por exemplo, uma função que gravaria dados confidenciais no banco de dados. Dessa forma poderíamos definir seu modificador de acesso como private e permitir que a mesma fosse acessada somente de dentro da classe e após uma minuciosa verificação nas informações que foram passadas pelo usuário, evitando os famosos SQL Injections, que são instruções maliciosas que procuram danificar ou roubar os dados do banco.

Mas voltando ao nosso exemplo, da forma como nosso código do método getCor está agora, ou seja, com o modificador private, ele não mais pode ser acessado de fora da classe, mas somente de dentro dela, ou seja, de dentro do método setCor nós podemos chamá-lo, vejam:

No fundo é tudo muito simples, mas a importância dos modificadores de acesso é imensa e é muito importante que você os entenda.

Ainda na imagem acima é importante notar que as variáveis sCor e sMarca não possuem modificadores de acesso explícitos, mas na verdade eles existem. O C# trata, inteligentemente, todas as variáveis com modificadores não declarados como Privates. Ou seja, deixar o código acima como está ou fazê-lo com as palavras Private é a mesma coisa, vejam:

Se alterarmos isso para public, mesmo de fora da classe elas ficarão disponíveis para acesso, vejam:

Essa prática não é recomendada, pois a organização e a segurança que a POO nos oferece fica enfraquecida quando se altera variáveis da instância de um objeto diretamente. É aconselhável deixa-las sempre como private e somente efetuar a manipulação dos seus valores de dentro dos métodos da classe.

O básico sobre encapsulamento e modificadores de acesso é isso. Não vou falar agora sobre o tipo Protected, pois para isso seria preciso já ter falado sobre herança, então o farei no momento oportuno.

Vou deixar de lado o Internal, que só faz sentido em soluções muito grandes, que possuem mais de um projeto e, como o objetivo destes tutoriais é dar uma introdução à POO, não vejo sentido em citar um assunto que seguramente não será usado por alguém que esteja tendo seu primeiro contato com POO agora. Acho que só tumultuaria as coisas, mas, apenas para saciar sua curiosidade, ele não tem nada de complexo e basta pensar que atributos ou classes definidas como Internal somente podem ser acessadas de dentro do seu próprio assembly(Project, no Visual Studio). É importante também não confundir os Projects com as Solutions. O Visual Studio permite que uma Solution contenha vários Projects. Enfim, não se preocupe com este tipo de modificador de acesso. O importante é encerrar este tópico sabendo que é possível proteger os dados para que sejam acessados somente através de métodos específicos. Prossigamos nosso minicurso falando no tópico seguinte sobre "herança".