Por que essa coisa de variável private?

21 respostas
S

é isso mesmo, eu tô fazendo um programa que precisa instanciar objetos por cima de objetos e guardar os valores inerentes a cada coisa q ele recebe de parâmetro de modo que eu possa trabalhar com os dados. Acontece que se eu colocasse as variáveis das classes (que são 8 até agora) como private eu não conseguiria acessar tais variáveis sem criar um método pra isso.

pois eh, eu sei, eu sei que existe akela coisa de "hermetizar o código", e que é importante, mas eu preciso acessar tais variáveis de forma simples e rápida. Existe outra coisa semelhante ao private que proteja as variáveis contra o "mundo exterior" mas que me permita acessar elas dentro da classe que chama a outra classe?

por exemplo, vejam o tamanho do construtor maior até agora:

[code]
Habilidade(boolean agressiva, String tipo, String nome, Varia varia,
Corretor corretor, Atributo atributo, Custo custo){
...
}
e cada um desses objetos tem variáveis internas a eles q eventualemte eu posso precisar utilizar...

21 Respostas

F

implemente metodos setXXX e getXXX para cada variavel que voce possue na sua clase, estes metodos acessam as variaveis facilmente e ainda por cima fica no padrão java beans

public class Teste {
                private Object Objeto1;
                public Teste() {
                         ... //alocações
                }

                public void setObjeto1(Object newObject) {
                        this.Objeto1 = newObject;
                }

                public Object getObjeto1() {
                        return this.Objeto1;
                }
                 


      }

ps, não esqueca do contructor sem parametros … :smiley:

H

Cara, não entendo corretamnete o que vc ker fazer? De uma olhada nos modificadores, estude-os direito, vc poderia estar utilizando estas propriedades protected ou com modificador default, porém deverá seguir algumas regras.

[]'s

D

É como naquela antiga propaganda de água tônica: “É diferente mas você se acostuma” (algo assim).
Esse é o padrão para se acessar as variáveis de uma classe. Você pode ainda usar modificadores protected ou default em casos bem específicos, mas não vai fugir de fazer muitos Gets e Sets.
Logo logo você vai estar escrevendo algo assim:

habilidade.getCorretor().getNome();
D

Você utilizar atributos privados e disponibilizar métodos set e get públicos dá no mesmo que você fazer os seus atributos serem públicos, pelo menos no que tange sobre acessibilidade, sem falar de outros aspectos.

Veja qual a melhor solução para você e siga em frente. Eu, particularmente, prefiro os getters e setters.

W

private - so sao acessados pela propria classe
protected - podem ser acessados tb pelas classes q a extendem
public - qualquer um pode acessar

S

ae povo, valew, mas é justamente esse mar de get e set que me incomoda.
o negoço do protected é interessaente, pena que só dê pra usar se estender.
eu tinha visto protected no src uma vez mais num entendi pra que servia.

então vcs realmente afirmam com categoria que, se eu quiser seguir o padrão da sun vou ter que por as variáveis private e colocar get e set?
ok, vou filosofar sobre isso, :frowning:

ademais muito obrigado a todos que responderam. essa coisa de aprender java fica mais fácim com uma comunidade interia como tutora, ehehehe…

ah, e quando ficar pronto, eu divulgo os fontes aqui pra vcs poderem jogar o jogo tb, ehehehe…

P

Creio que o que você espera é selective export, a habildiade de exportar membros de uma classe apenas para alguns poucos selecionaos, como funções friends em C++. Issof az muita falta no java mesmo.

1 - NUNCA altere uma variável diretamente, a não ser que esteja definitivament efazendo uma gambiarra

2 - Crie uma interface que seus clientes “normais” usam, sem os métodos get/set (se utilizar essa nomenclatura) dos atributos que devem ser privados e uma interface para quem precisar acessar oe stado interno.

Exemplo:

class Pessoa implements Usuario, Membro{
 private nome;
 private login;
 private senha;
 
 getNome(){...}
 setNome(){...}

 getLogin(){...}
 setLogin(){...}

 getSenha(){...}
 setSenha(){...}
 boolean validarSenha(String senha){...}
}

interface Usuario{

 getNome(){...}
 setNome(){...}

 getLogin(){...}

 boolean validarSenha(String senha){...}
}

interface Membro extends Usuario{

 setLogin(){...}

 getSenha(){...}
 setSenha(){...}
}

Quando você rpecisar tratar de uma forma mais “Normal”, use Usuario, quando rpecisar acessar as outras funções, use Membro.

S

pronto, era isso mesmo. kra, eu expliquei bem mal e tu capitou muito bem, ehehehe…
pois eh, eu tô acessando todas as variávei diretamente, mas isso não é bom. aí eu poderia fazer interfaces fazer isso por mim? hum… vou ver qq eu posso fazer, e valeu mesmo! é hora de trabalhar!

I

E ai Leonardo :slight_smile:

O problema não é nem com os metodos get/set, e sim com a base da orientacao a objetos. Teoricamente, voce nunca deveria precisar ler os atributos de um objeto, já que ele seria o responsavel por manusear os seus proprios recursos e prestar os servicos desejados, devolvendo apenas os resultados.

Como isso nem sempre é possivel, ficou “convencionada” a utilizaçao dos getters e setters para acessar esses atributos, mas isso é voce quem decide. Há quem ache que isso é gambiarra da Sun, outros acham uma maravilha.

Existem algumas vantagens em se utilizar essa convençao. Por exemplo, se a estrutura do objeto muda, o nome do metodo pode ser mantido (garantindo a compatibilidade), enquanto o metodo em si é alterado para se adequar à nova estrutura. Outro caso interessante é o tratamento de erros: quando um objeto altera diretamente um atributo de outro, nao há como saber se os valores que ele inseriu sao “válidos”. Atraves de um método, voce pode fazer todos os testes e gerar uma exceçao, se for o caso.

Se quiser ler mais sobre o assunto:
Why getter and setter methods are evil

Entao, resumindo: nao leia os atributos de outros objetos, peça a eles a informaçao já processada.
Se isso não é possivel, faça da maneira “menos pior”, usando get/set. :wink:

[]'s

L

Existe uma razão para os atributos serem de preferência private, é porque um objets não devem se intrometer no estado dos outros.

Ou seja, em vez de pegar os atributos de um objeto para fazer alguma coisa, mande esse objeto fazer e use o resultado. Isso é encapsulamento, não setters e getters.

W

galera, mas tipo, aproveitando o assunto, vcs acham q mesmo qdo os metodos sao feitos para isso em geral (apenas guardar dados numa estrutura), no kso, dados sem processamento nenhum (como guarar apenas o nome de um usuario e seu ID)

vcs acham nesse kso um bom uso de variaveis public?? tem outro geito de fazer esse tipo de coisa sem ser usando classes?

P

Não.

Wilker:

tem outro geito de fazer esse tipo de coisa sem ser usando classes?

Tem, use C++ :wink:

Na boa, se você não vai programar OO, existem linguagens melhores que java (se vai também).

Aidna que você esteja usando programação procedural (ou programação JavaBean), pelo menos use get/set. É uma cosia ruim, mas pelo menos já é algo…

L

Se o teu programa não faz nada de util com esses dados, por que eles existem? :wink:

W

tipo, eu vo usa esses dados sim, as classes tao sendo usadas pra guarda eles, por exemplo, eu extendo um treenode, nomeio ele com mynode, e esse mynode recebe tb um argumento User, q eh uma classe q contem nome e login de usuario, mas tipo, esses dados sao separados por usuario, e nao precisam de processamento de validacao nenhum, e podem ser alterados sem problema a qq momento, eh pra esse kso q eu digo q eu uso public

W

pcalcado:
Wilker:

vcs acham nesse kso um bom uso de variaveis public??

Não.

Wilker:

tem outro geito de fazer esse tipo de coisa sem ser usando classes?

Tem, use C++ :wink:

Na boa, se você não vai programar OO, existem linguagens melhores que java (se vai também).

Aidna que você esteja usando programação procedural (ou programação JavaBean), pelo menos use get/set. É uma cosia ruim, mas pelo menos já é algo…

kra, eu adoro programar OO, mas esse eh um tipo de kso especifico, e eu realmente n acho nescessario criar metodos pra variaveis q podem ser alteradas de qq maneira…

I

Acessando diretamente os atributos, voce precisaria conhecer a estrutura interna do objeto, o que violaria totalmente o encapsulamento. Entao, se for pra programar OO violando os principios basicos, é melhor nem programar. No fim das contas, seu codigo sai uma bagunça só. :roll:

[]'s

W

eu n acho bem assim kra, tipo, eh otimo fazer isso, eu prefiro usar uma classe de estrutura do q criar arrays bidimensionais (q seria o kso de programacao estrutural)

mas isso eu acho q eh questao de gosto e nescessidade, alem de q, a classe foi criada por mim, e soh vai ser usada por mim internamente nakele programa, entao eu n vejo problema do uso public, ateh porque, c realmente fosse um pecado usar variaveis public, elas n existiriam :wink:

I

Mas você pode usar classes em programaçao estruturada. :slight_smile:

E não é nenhum crime ter um objeto responsável por organizar o acesso a outros objetos. Se fosse, as classes de coleção não existiriam. Só nao entendi ainda porquê voce diz que seria melhor acessar diretamente os atributos.

[]'s

P

Isso não procede, você pode usar registros em programação procedural, e é exatamente isso que se faz.

Em OOP você não deve expôr esses dados livremente, só isso.

L

Falta CRC no teu código.

S

ei pessoal, a solução de interfaces parece meio complexa… pesquisei o assunto mas não encontro material que demonstre o evento. bom, de qq forma, eu estou esperando uma ajuda ainda…
vejam, o código utiliza as seguintes classes:

Personagem

Potenciais
Habilidade

Variação
Corretor
Atributo
Custo

além de outros valores primitivos mais simples de se trabalhar. Observem que quatro destas classes são entrada de parâmetro para uma que por sua vez constitui um array dentro da classe maior. O meu problema é passar de forma simples e segura dados através destas classes em qualquer sentido e para qualquer nível.

-tornar algumas destas classes classes internas ajuda?
-criar uma classe para fazer storage de dados é uma boa idéia?

só tenho dúvidas.

Criado 23 de abril de 2005
Ultima resposta 26 de abr. de 2005
Respostas 21
Participantes 9