encapsulamento

Thread.start() Membro desde: 01/04/2006 13:45:33 Mensagens: 46 Offline

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.

JavaChild Membro desde: 05/09/2007 15:46:13 Mensagens: 102 Offline

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

Thread.start() Membro desde: 01/04/2006 13:45:33 Mensagens: 46 Offline

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

This message was edited 1 time. Last update was at 24/03/2008 13:34:56

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....

heliob wrote: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

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....

Thread.start() Membro desde: 01/04/2006 13:45:33 Mensagens: 46 Offline

ué, mas não se trata um valor antes de setar ele a algum atributo do objeto??

Abraços,
Hélio

This message was edited 1 time. Last update was at 24/03/2008 13:45:07

heliob wrote:ué, mas não se trata um valor antes de setar ele a algum atributo do objeto??

Abraços,
Hélio

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....

Thread.start() Membro desde: 01/04/2006 13:45:33 Mensagens: 46 Offline

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

JavaChild Membro desde: 05/06/2006 23:52:12 Mensagens: 105 Offline

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.

rfgallon wrote:Primeiro gets e sets é uma convenção chamada (JavaBeans). Dá uma olhada nisso http://java.sun.com/docs/codeconv/

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.

Notícias, artigos e o maior fórum brasileiro sobre Java