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 é 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:
[quote=“cleo_nascimento”]
Em estruturado: função e variável e em OO: Metodo e campo.[/quote]
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? :?: :???:
[quote=“cleo_nascimento”]pcalcado, acho que está sendo gerado um enorme equivoco!
[/quote]
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.
[quote=“cleo_nascimento”]
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![/quote]
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ê:
[quote=“vinod_unny”]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[/quote]
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.