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".
HARDWARE
Entendendo o seu computador
O que há dentro do meu computador?
Existem alguns componentes fundamentais presentes dentro do seu computador e é muito importante que você conheça um pouco sobre eles, seja para argumentar com algum vendedor durante a compra de um novo PC ou para identificar alguma atitude desleal de algum técnico que esteja te passando um orçamento para reparo. Na seção Raio-X aqui do Contém Bits você pode conhecer e entender mais detalhadamente sobre cada componente, ou também pode clicar abaixo no componente que deseja, para conhecê-lo melhor.
Você Sabia?
Mega Man
A primeira versão do clássico Mega Man, para Nintendo 8 bits, tem seu recorde de pontos estabelecido em 03/11/2006, por David Archey, que cravou 2.396.700 pontos, terminando o jogo.
Playstation
O Playstation só nasceu porque uma parceria entre Sony e Nintendo, para desenvolver uma unidade de CD para o Super Nintendo, fracassou. Clique aqui e saiba mais.
Tetris
Desde o seu lançamento, em 1985, o fantástico jogo Tetris vende pelo menos 70 milhões de unidades por ano em todo o mundo! Os dados são oficiais e fornecidos pela THQ, uma das distribuidoras do título.
Mario em Donkey Kong
O personagem Mario surgiu pela primeira vez no mundo dos games em um jogo chamado Donkey Kong, lançado em 1981. Mario, que naquela época se chamava Jumpman, não era o personagem principal do jogo, mas ele se tornaria um dos mais famosos personagens do mundo dos games. Saiba mais.
Duck Hunt
Ao completar o nível 99 do jogo Duck Hunt, para Nintendo, o jogo retorna ao primeiro nível, mas um bug impede que se acerte os patos neste recomeço. Este é um exemplo do que é chamado no mundo dos games de "Kill Screen".
Recorde de patentes
A IBM detém o recorde de patentes em um único ano, atingindo a marca de 4186 registros no ano de 2008. Clique aqui e saiba mais sobre esta gigante do mundo da tecnologia.
Final Fantasy X
O jogo Final Fantasy X para o Sony Playstation 2 vendeu, apenas no dia do seu lançamento, 1.455.732 cópias, estabelecendo um recorde de vendagem para as primeiras 24 horas de um game. Méritos da SquareSoft, que desenvolveu um excelente produto!
Street Fighter 2
Street Fighter 2, lançado para o Super Nintendo no início dos anos 90, foi o principal responsável pelo aumento nas vendas deste console. Graças ao sucesso do título nos Arcades e à perfeita adaptação ao console, muitos consumidores adquiriram o SNES para jogarem o título em casa. Saiba mais.
Ábaco
O ábaco é o dispositivo de cálculo mais antigo construído e conhecido pelo homem. Suas formas mais primitivas datam de 400 a.C. e eles foram encontrados na China e na Babilônia. Para saber mais sobre a história dos computadores, clique aqui.
Donkey Kong
A empresa Universal City Studios, detentora dos direitos autorais do King Kong, processou a Nintendo logo após o lançamento de Donkey Kong, pois segundo ela, o game violava os seus direitos. Ela venceu o processo e recebeu da Nintendo uma indenização de quase 2 milhões de dólares.