Olá, sou aprendiz de java.
Em relação a encapsulamento, pq privar os atributos? Estou lendo que se trata-se de segurança.
Digamos que eu tenha um objeto conta com atributo saldo.
Quem além do programador iria conseguir alterar o saldo??
Atenciosamente,
Hélio
Leia mais sobre isso cara ele não é totalmente privado e sim tem uma forma mais segura de ser acessa-lo.
leia um pouco mais sobre get and set.
att,
Alan Rodrigo.
Bom Helio,
Eu acho que se usa separar variaveis para uma manutenção mais facil do software, sem que outros objetos sejam alterados.
Encapsular atributos também auxilia a garantir que o estado e o comportamento de um objeto se mantenha coeso.
Bom acho que seria mais ou menos isso…Alguem com mais experiencia pode responder melhor…estou comecando tbm… rs
[]´s
Sim… eu li sobre get e set, mas não entendi o pq do trabalho de cria-los.
Minha duvida é pq definir como private, sendo quem vai usar o objeto é o proprio programador…
Pq se dar ao trabalho de criar gets e sets para alterar um valor de um atributo ao qual só o programador vai mexer…
Abraços,
Hélio
ao criar get e set vc garante a maneira de se setar um atributo por exemplo, para setar um int por exemplo vc passar objeto.setAtributo( 8 )… e se o atributo fosse publico vc poderia atribuir um valor -10 por exemplo…
imagine a altura da pessoa sendo setado com -1,70… :?:
[quote=heliob]Sim… eu li sobre get e set, mas não entendi o pq do trabalho de cria-los.
Minha duvida é pq definir como private, sendo quem vai usar o objeto é o proprio programador…
Pq se dar ao trabalho de criar gets e sets para alterar um valor de um atributo ao qual só o programador vai mexer…
Abraços,
Hélio[/quote]
imagine uma equipe de 5 programadores… e eles dependem do seu código…
um outro programador pode fazer uma merda na funcionalidade porque vc simplesmente deixou ele fazer tudo e deixou tudo público…
a culpa é tanto sua quanto dele, ele porque não sabe programador e tá fazendo gambiarra…e sua culpa porque não encapsulou e deixou público (gambiarra do mesmo jeito)… vc confiou nos outros programadores…
ué, mas não se trata um valor antes de setar ele a algum atributo do objeto??
Abraços,
Hélio
[quote=heliob]ué, mas não se trata um valor antes de setar ele a algum atributo do objeto??
Abraços,
Hélio[/quote]
e se o outro programador que citei não tratar esse valor:?:
ou se ele não previu, que isso poderia acontecer :?:
vc vai confiar nele desse tanto :?:
a culpa é sua e dele…entende…esse ponto que vc tem q entender…num projeto trabalham diversas pessoas… então vc tem tomar certas garantias…
além do que isso é padrão… tem muitas coisas que aumentam o trabalho pra deixar dentro do padrão e ser algo proveitoso no futuro, por exemplo, comentários de código, é algo simples de fazer, tem um padrão definido pela Sun, e se futuramente seu código não tiver sido comentado, alguém for dar manutenção, sem comentário fica um cáos total…
comece a ver as coisas por esse lado… tanto de funcionalidade no momento quanto futura…
Certo, entendi… mas mais uma dúvida:
Se um terceiro instanciar um objeto de uma classe que vc criou e tentar setar algum valor através um método feito nos “padrões do encapsulamento” com um valor não condizente ao valor válido aquele atributo, não vai ocorrer a excessão de qualquer maneira??
Desculpa por eu ser chato, mas OO é punk de entender…
Vejo coisas, que a principio, são desnecessárias.
Mas tenho ciência que se existem é pq já foram testados, re-testados e hoje em dia é usado assim, baseado na premissa que foram caras super phodas que criaram esse conceito, e não a toa…
Abraços,
Hélio
Abraços,
Hélio
Vai ocorrer uma exceção, que vai documentar o problema.
Pior é se seu atributo aceitar silenciosamente o valor inválido e o seu sistema começar a se comportar de maneira cada vez mais estranha.
Além disso, seu método não precisa necessariamente deixar o usuário escolher o valor do atributo. Por exemplo, no caso da classe Semaforo, você pode ter o método trocaCor(), que automaticamente define a próxima cor, tornando impossível a colocação de uma cor inválida, e o método getCor().
Olá,
Sobre encapsulamento - na verdade information hiding - leia: http://en.wikipedia.org/wiki/Information_hiding
Sobre contratos entre os objetos e seus clientes, uma leitura sobre Design By Contract vai te esclarecer algumas dúvidas: http://en.wikipedia.org/wiki/Design_By_Contract
E uma artigo onde o Phillip Calçado fala sobre Contatos Nulos: http://www.fragmental.com.br/wiki/index.php/Contratos_Nulos
[]s
Primeiro gets e sets é uma convenção chamada (JavaBeans). Dá uma olhada nisso http://java.sun.com/docs/codeconv/
Outra questão é o que já foi citado aqui, você pode ter uma equipe trabalhando no projeto ou essas tuas classes podem virar um pacote ser distribuido, ou você pode a qualquer momento fazer uma caquinha e dai já viu né, vai perder tem localizando problema, se fizer de acordo com o padrão basta fazer um debug no lugar correto que poderá identificar o mesmo.
[quote=rfgallon]Primeiro gets e sets é uma convenção chamada (JavaBeans). Dá uma olhada nisso http://java.sun.com/docs/codeconv/[quote]
Acho que não… os javabeans realmente convencionaram os gets e sets, mas a especificação vai muito além disso.
Agora, encapsular dados de dentro do objeto através de propriedades é um conceito antigo, já existente no Delphi, por exemplo, que fazia através de uma palavra reservada (Property). No C++, esse idioma também já foi usado também e através de métodos, tal como no Java. Embora por lá não haja uma padronização de nomes.