Eu já entendi pra que serve,a teoria tal, mas alguem poderia me dar um exemplo e explicar esse exemplo um pouco detalhado?
Valeu desde já!!!
Encapsulamento?
30 Respostas
encapsulamento é uma função que serve para voce acessar uma variavel
privada daquela classe Ex;
private int A=0;
/vamos supor que a variavel A nao possa receber valores menores que 0, entao voce cria uma funcao que ira permitir somente a entrada de valores maiores ou igua a 0/
public void setVar(int x){
if(x>=0)
A=x;
else
System.out.print(“erro”);
}
/*em uma outra classe eu não poderia chamar a variavel A pois ela é privada desta classe, se pudesse eu poderia colocar qualquer valor dentro de A, mas ela só pode receber valores maiores ou igual a 0 para isso tem a classe publica setVar que podera atribuir valores a A desde que seja maior ou igual a 0 */
/É para isso que serve o encapsulamento, proteger uma determinada variavel para que só possa entrar valores validos./
Valeu Jamati, era isso mesmo que eu queria saber, tava lendo o livro do Deitel agora mesmo e me deparei com o que tu posto, ´so que tu foi direto ao assunto!
Até a próxima…
Encapsulamento é uma das regras de OO e não uma função, ela serve para esconder como o próprio nome já diz. Em java existe 7 tipos: public, private, protected, static, interface, abstratic e final; o qual também é chamado de chaves.
O que muinta gente erra!
Em estruturado: função e variável e em OO: Metodo e campo.
o nosso amigo CLEO esqueceu o tipo de encapsulamento PACOTE…que também existe…
Olá,
Cuidado com a confusão.
private, public… são modificadores, um recurso da linguagem.
Encapsulamento é a técnica de esconder a implementação de um recurso. Sabe uma capsula de remédio? Sabe quando é transparente e tem umas bolinhas dentro? Como você toma o remédio, você abre a capsula e ingere as bolinhas ou engole a capsula?
A capsula esconde os detalhes, por ela você não repcisa saber se o que tem dentro são bolinhas, é um líquido ou são pequenos gnomos que agem no seu organismo. Não interessa, o que interessa é que você consegue usar o remédio e amanhã se o fabricante subsctituir as bolinhas por nano-robôs, voce não vai notar diferença.
Get e set são convenção adotada em java para mutators e acessors, se você declarar tudo private e expôr tudo via get/set, não está encapsulando nada.
me desculpe companheiro pois realmente esqueci de mencionar o tipo package, enquanto ao nosso amigo pcalcado, ninguem em seu estado normal e que detenha os conhecimentos de lógica programacional irá sair declarando tudo em um algaritmo como private ou protected, pois lembra do preciosismo; tem que se ter realmente um motivo louvável para ser utilizado.
Cleo, desculpe se te ofendi, estava apenas tetnando esclarecer uma coisa.
Encapsulamento não é modificador (na verdade você pdoeria ter encapsulamento total sem nenhum membro private, basta usar interfaces), nem uma função para acessar variáveis (isso é um getter/acessor).
Na verdade, a linha de pensamento em OOP é exatamente o contrário: declare tudo privado a menso que realmente seja necessário expôr. Não é preciosismo, é encapsulamento.
pacaldo, as descordias também servem para o alto-amadurecimento do conhecimento, sendo assim não me senti desconfortável com seu ponto de vista! Outra coisa, eu acho que você está equivocado na questão de modificadores; pois eu em momento algum falei, que o Encapsulamento seja um modificador, mas que se trataria de uma regra de OO; o método set também é conhecido como: modificador, trasformador ou multator.
Bem, disse sim:
Ou eu entendi errado.
Estes são os modificadores. Pode existir modificador sem encapsulamento, pode existir encapsulamenteo sem modificadores.
E acrescentando ao debate:
Em estruturado: função e variável e em OO: Metodo e campo.
Em OOP creio que seria Estado e Comportamento.
Atributos e funções(métodos) são comuns também em paradogma estruturado (por exemplo em C eu posso ter uma struct com atributos e funções).
pcalcado, acho que está sendo gerado um enorme equivoco!
Pois para se ter um bom encapsulamento, tem que se ter incluso na sintax da linguagem os tipos private e protected, para que os dados contidos no algoritmo sejam seguros; coisa que Java tem, e por isso é uma linguagem que chega a ter 100% de OO.
se encapsulamento nao é usar public, protected, private é o q entao? :?: :???:
pcalcado, acho que está sendo gerado um enorme equivoco!
Sim está…
Encapsulamento sem modificadores:
interface Servico{
public void facaAlgo();
}
class PrestadorDeServico implements Servico{
public int a=9;
public String nome="Jose Encapsulado da Silva";
public String metodoSecreto(){
return nome;
}
public void facaAlgo(){
i=i+i;
}
}
class Bla{
public static void main(String[] s){
Servico encapsulado = new PrestadorDeServico();
encapsulado.facaAlgo();//funciona
//encapsulado.nome="Pedro Pedreira"; <- nao compila
}
}
Percebeu? Tudo é public mas a interface me dá os meios necessários para encapsular o comportamento da classe.
Além disso, Java não é 100% OO e não será enquanto ainda tiver tipos primitivos. Da mesma maneira, C++ é de chamado multi-paradigma (características de estruturada e de OO) e mesmo assim possui ainda mais modificadores de acesso que java. 
Bons autores sobre o tema são Bertrand Meyer, Page-Jones, Bruce Tate, Martin Fowler e Joshua Bloch, entre muitos outros
pcalcado, Java não é 100% OO? foi à linguagem eleita pela comunidade de TI, como a que mais aplica as técnicas. Em minha opinião só faltava ter heranças múltiplas, mas esse é outro assunto a ser discutido e se vale à pena ser incorporado.
As Interfaces, não foram criadas para esta finalidade em especifico, e sim como fonte para plugins (melhoramento de performance), esse é o melhor método de se usar interfaces.
interface Servico{
public void facaAlgo();
}
class PrestadorDeServico implements Servico{
// Cléo Nascimento: public int i;
public int a=9;
public String nome=“Jose Encapsulado da Silva”;
public String metodoSecreto(){
return nome;
}
public void facaAlgo(){
// Já que quer usar i= i+i usa i+=i, surte o mesmo efeito;
i=i+i;
}
}
class Bla{
public static void main(String[] s){
Servico encapsulado = new PrestadorDeServico();
encapsulado.facaAlgo();//funciona
//encapsulado.nome=“Pedro Pedreira”; <- nao compila
}
}
Obs: JCP, que tem nos principais países desenvolvedores em Java!
No Brasil tem! é a reguladora do algoritmo javanês, e esta lógica usada por você, não condiz com as normas da JCP sendo assim, desaprovada! Sei que é só um exemplo, portanto é admissível porem tem que ser endossada como exemplo não praticável!
Não consegui etnender muito que você disse, mas vou tentar responder…
Não. Não háo que discutir, faça uma busca na Internet, Java é uma linguagem hpibrida, ao contrário de python, ruby, smalltalk, eiffel…
Que eleição foi essa? ALgum link? QUe técnicas?
Concordo, ams a falta não é grande o suficiente.
1 - Plugins e performance não tem nada relacionado, plugisn são mecanismos de extensibilidade
2 - Interfaces para plugins? Interfaces são contratos, você pode ter interfaces sem plugisn e plugins sem itnerfaces (caso contrário programas em C++ não teriam plugins, e meu Winamp diz o contrário).
Ok, falha minha.
Obs: a JCP, que tem nos principais países que desenvolve em Java;
no Brasil tem, é a reguladora de como se escreve o javanês, e esta lógica usada por você, não condiz com as normas da JCP sendo assim, desaprovada! Sei que é só um exemplo, portanto é admissível porem tem que ser endossada como exemplo não praticável!
Eu perdi alguma coisa aqui. O JCP - Java Community Process é um órgão, sem filiais (tem brasileiros no JCP, não tem JCP no Brasil!) e eu não sei de onde você tirou que o JCP aprova ou desaprova alguma lógica!
Por favor, me de referências. Links, artigos, livros, qualquer coisa que me faça entender o que voc~e quer dizer.
Java foi eleita como 100% OO, por ser a primeira desenvolvida apenas nesta lógica, e por aplicar totalmente as três regras de OO e ser bem definidas: (Herança, Encapsulamento e Polimorfismo).
Vai um forun falando a respeito.
http://forums.pcquest.com/forum/viewtopic.php?p=9115&sid=9c753b5a3beb9990c361bd9a4520c0bc
Onde eu li que a JCP tem no Brasil, foi na revista: “MUNDO JAVA” deste mês!
Elas têm sim um peso importante sobre as decisões na lógica javanesa.
Eu disse que as interfaces podem ser usadas como plugins, e que geralmente.
é usado desta maneira, vale salientar que vai de cada projeto!
Desculpem-me, mas relendo a revista constatei que eu estava equivocado, não é que tem JCP no Brasil, mas que existem 27 brasileiros membros.
Acho que continuo não entendendo. Nesta thread que você passou o link diz que Java não é 100% OO pelo mesmo princípio que eu falei para você:
Well, that statement is actually true. Java is not 100% object oriented, althugh it comes close. Smalltalk and C# are perhaps the nearest to 100% OO as can be.For instance, in Java, primitive types are just that - primitive types. Whereas in langs like Smalltalk and C#, even primitive types are Objects. So things like “char”, “int”, “byte” etc. are all objects (System.Object being the root). In C# you can even call methods on actual entities - for instance you can do things like: 100.ToString().
This is just one example. There are many others as well.
http://c2.com/cgi/wiki?IsJavaObjectOriented is a good discussion on the above topic
Meu inglês está tão ruim assim?
Para continuar debatendo: você pode fornecer alguma fonte informando que o JCP diz que Interfaces são geralmente usadas para plugins, que encapsular com itnerfaces não deve ser feito ou qualquer outra coisa?
O JCP define especificações para a plataforma Java e até hoje eu não vi nenhuma JSR sobre programação OO em Java por este órgão.
pcalcados, não vejo problema algum na OO em Java!
Gostaria que apontasse os erros na teoria da OO original e conflitasse com a que todos nos aprendemos em Java.
Tirando Design by Contract, Herança Múltipla, sobrecarga de operadores, a coisa que realmente nãod eixa java ser 100% OO é a presença de não-objetos
Como você pode ter uma linguagem 100% OO com int, char… que não são objetos? E não, autoboxing não é solução, é gambiarra.
Memos assim, java é uma das linguagens com maior aceitação no mundo da OOP, implementando coisas muito legais como interfaces, reflexão e polimorfismo real.
Alguns dos recursos que faltam no Java podem ser encotnradas em linguagens alternativas, como groovy e jython.
Verdade seja dita, faltão alguns conseitos sim! mas acho que você se equivoca quando diz que java não tem objetos, pois um objeto nada mais é que um atributo que foi instânciado!
Obs: java possue todos os tipos primitivos e derivados!
Eu te convido a mostrar onde eu disse isso.
Errado, você está confundindo alguma coisa que aidna não identifiquei.
Objeto é uma entidade de software que possui comportamento e estado definidos. Se fosse assim, qualquer linguagem seria OO.
Obs: java possue todos os tipos primitivos e derivados!
Todos? Quais? Possui union? Possui dicionarios? Possui tipos unsigned?
De onde você tira essas coisas, afinal?
Já ficou improdutivo. Você não citou nenhuma referência (exceto uma que dizia exatamente o contrário que você dizia, e mesmo assim uma thread num fórum, nada oficial), fala que eu escrevi cosias que não escrevi (talvez você também não esteja me entendendo, sei lá) e eu simplesmente não consigo entender o que você quer dizer.
Paro por aqui.
Recomendo que você procure um dos livros que indiquei para entender mais um pouco sobre o que um objeto é e no que ele difere de uma variável. Aprender um pouco a mais é sempre bom 
[]s
Tudo bem! acho que eu não compreendi por completo o que você quis passar, e que também não fui claro a passar meus pensamentos!
Acho que a dúvida do nobre amigo já foi solucionada, e que estamos discutindo algo que não vale a pena no presente momento.
Outro fato é que não conheço a fundo estas linguagens que você menciona, portanto não gosto de comentar aquilo que desconheço, prefiro estudar e depois falamos mais sobre elas. Eu tenho conhecimentos em c++, Java, delphi, javascript, asp e php; e dentre estas e muitas outras, Java consegue ser a mais OO de todas!
Obs: sendo que há muito tempo só vivencio com Java!
E no final das contas tudo se resume a interpretação de texto.
Sem querer fomentar a discussão, ou como dizem, o discursão, fiquei assustado ao ler isso: “um objeto nada mais é que um atributo que foi instânciado”.
Um atributo (ou variável) é uma das “faces” do objeto, a outra é o comportamento (ou métodos). Ou eu perdi algo?
O certo seria “um objeto é uma classe que foi instânciada”. A não ser que eu tenha cometido um erro de interpretação de texto.
Objeto é uma instância de uma classe, ou seja, se você fizer um “new AlgumaClasse()” vai estar sendo criado uma instância, ou seja, um OBJETO daquela classe.
Não sei se consegui te ajudar.
OBS: PESSOAL AO INVÉS DE FICAREM DISCUTINDO VOCÊS PODERIAM AJUDAR OS OUTROS, VOCÊS FALARAM TANTO QUE ACABARAM CONFUNDINDO O AMIGO QUE PRECISAVA DE UMA EXPLICAÇÃO SIMPLES, O QUE É OU NÃO É VARIAVEL, OU SEI LÁ O QUE VAI DE CADA UM, SÃO TUDO OPINIÕES, VAMOS APRENDER A RESPEITAR A OPINIÃO DOS OUTROS.
Tirando Design by Contract, Herança Múltipla, sobrecarga de operadores, a coisa que realmente nãod eixa java ser 100% OO é a presença de não-objetosComo você pode ter uma linguagem 100% OO com int, char… que não são objetos? E não, autoboxing não é solução, é gambiarra.
pra q ter herança múltipla no java?
o q eh sobrecarga d operadores e design by contract??
OBS: PESSOAL AO INVÉS DE FICAREM DISCUTINDO VOCÊS PODERIAM AJUDAR OS OUTROS, VOCÊS FALARAM TANTO QUE ACABARAM CONFUNDINDO O AMIGO QUE PRECISAVA DE UMA EXPLICAÇÃO SIMPLES, O QUE É OU NÃO É VARIAVEL, OU SEI LÁ O QUE VAI DE CADA UM, SÃO TUDO OPINIÕES, VAMOS APRENDER A RESPEITAR A OPINIÃO DOS OUTROS.
Olá,
Não entendi seu nervosismo e gritaria, isso aqui era um fórum da última vez que perguntei, e se você quer ajudar, que tal responder ao que ele perguntou?
Pergunta:
Você tem certeza que leu ot tópico?
Enfim, caso você tivesse lido, ia saber que a resposta já foi alcançada
Valeu Jamati, era isso mesmo que eu queria saber, tava lendo o livro do Deitel agora mesmo e me deparei com o que tu posto, ´so que tu foi direto ao assunto!
Até a próxima…
E onde está a regra dizendo que a discussão de um tópico não pdoe mduar de assunto? Vamos aprender a ler…
Para evitar tanta delegação. Com o advento de AOP não tem sentido em usar herança multipla para incorporar serviços (como transações) a la C++, mas algumas hierarquias são melhor descritas com esse recurso.
o q eh sobrecarga d operadorese design by contract??
No Google você muitas fontes, mas são recursos de OOP que não existem em Java.
Sobre contratos:
www.fragmental.com.br/arquivos/contratosnulos.pdf
[]s
Objeto é uma instância de uma classe, ou seja, se você fizer um “new AlgumaClasse()” vai estar sendo criado uma instância, ou seja, um OBJETO daquela classe.Não sei se consegui te ajudar.
Se o que você escreveu foi para mim, então acho que você não entendeu o meu post.
Se todo mundo tivesse a mesma opinião não haveria evolução.
De vez em quando é bom um flamezinho (flame-war), desde que debatido num bom nível como fizeram o Shoes e o Cléo. E no debate deles surgiu muita coisa que, se não te ajudou, com certeza despertou curiosidade em outras pessoas (como aconteceu com o LichKing).
Com relação à nomenclatura, pode não ser um dos assuntos mais interessantes, mas muita gente se preocupa com isso (eu inclusive, apesar de não tanto quanto o Cléo).
E sobre respeitar a opinião dos outros, não vi nenhum deles desmerecendo a opinião do outro, apenas um tentando convencer o outro de que a sua opinião era a certa (discussão, certo?).
Acho que foi Voltaire que disse “posso não concordar com o que dizes, mas defenderei até a morte teu direito de dizê-lo”. Então, deixa os caras discutirem (desde que não haja ofensas).
pcalcado li sim sobre as linguagens que você mencionou em outro momento! e que você tem toda razão, pois Java não é 100% OO como eu pensava mais que dentre as linguagens mais populares como: Delphi, VB, .NET, C++ e outras, ela é a que mais consegue aplicar os conceitos de OO.
Falando na questão dos modificadores, o termo ficou incompleto, pois o termo correto seria modificadores de acesso!
Agradeço desde já, pela conversa construtiva em que realizamos; pois é com sobreposição de conhecimentos que aprendemos mais.