Opa!!!
Dúvida meio simples (creio eu).
Java é uma linguagem 100% OO ?
Complementando agora… o que chamam de uma linguagem 100% OO? E o que faz uma linguagem não ser 100% ?
Valeu
Não é 100% pq java é tipado. Mas isso está sendo amenizado com o J2SDK 1.5 em que será possível fazer:
Integer i = 1;Bem, considerando a maneira como o Rafael respondeu então devo me retratar: é 100% OO! 
Pow… onde tá oq o Rafael escreveu? hehehe
ué… só se ele deletou o post…
seguinte, java não é 100% OO não, pois os tipos primitivos não são objetos
e você pode fazer um programa apenas com metodos estaticos, o que o tornaria um programa 100% estrutural.
mesmo com o J2SDK 1.5 você não vai poder por exemplo fazer:
1.toString();
hahahaha… eu removi pq pensei estar falando idiotisse…
Eu disse que Java era 100% OO, mas nao sabia do lance dos tipos…
em contrapartida, disse tambem que, se uma linguagens nao implementa tudo o que a “especificacao” ( se eh que ha algo oficial ) da OO diz, como polimorfismo, heranca… se nao suporta classes, interfaces, classes abstratas etc, etc, nao daria para dizer que a linguagem em si eh OO, ja que ela estaria implementando apenas partes do conceito…
Rafael
Vc hein Rafael, utilizando do seus “super-poderes” de moderador para tirar uma com a nossa cara… 
Por isso eu disse que “amenizaria”.
[quote=“Rafael Steil”]hahahaha… eu removi pq pensei estar falando idiotisse…
Eu disse que Java era 100% OO, mas nao sabia do lance dos tipos…
em contrapartida, disse tambem que, se uma linguagens nao implementa tudo o que a “especificacao” ( se eh que ha algo oficial ) da OO diz, como polimorfismo, heranca… se nao suporta classes, interfaces, classes abstratas etc, etc, nao daria para dizer que a linguagem em si eh OO, ja que ela estaria implementando apenas partes do conceito…
Rafael[/quote]
Vc hein Rafael, utilizando do seus “super-poderes” de moderador para tirar uma com a nossa cara…
Uma duvida boba:
Um linguagem que não implementa herança multipla de classes pode ser considerada 100% OO?
Aí é que tá… vc pode simular isso com interfaces, mas não é a mesma coisa, já que os métodos de interfaces são abstratos, portanto vc tem isso em tese mas não na prática.
O fato de java não suportar herança múltipla é considerado pela oposição um ponto negativo… mas particularmente não vejo isso como limitação, já que herança múltipla é um negócio extremamente perigoso e muitas vezes sem sentido.
Eu também acho que usar herança multipla de classe é uma bomba-relogio.
será que isso importa mesmo pra ser 100% OO? Eu acho que não;
Bom…
enxergo de duas maneiras…uma seria assim…java pode implementar todos os conceitos de OO ? Sim, então é 100% OO…não ?..então não podemos falar que é 100% OO
No entanto, sabemos que algumas coisas no Java fura o conceito 100% OO…como foi citado aqui…no entanto, o lance é?!
Posso fazer um programa OO…pode sim!!
Acho que é uma longa discussão… 
ate mais…
Tipagem forte ou fraca (ou estatica/dinamica) nao tem naaaaada a ver com OO. Depois, toda linguagem é tipada, salvo raras excecoes
Péééé de novo. Uma linguagem OO nao precisa ter classes ou interfaces. Ela precisa ter heranca, encapsulamento e polimorfismo. Essa eh a “especificacao” da OO, se eh que existe algo desse tipo. JavaScript, por exemplo, eh OO e nao tem classes, mas sim prototipos.
Sim, perfeitamente. O que importa eh ter heranca, se eh multipla, simples, de ponta cabeca ou azul de bolinhas amarelas, nao vem ao caso se o que vc quer é saber se a linguagem eh OO ou nao.
Respondendo à pergunta: Java nao eh 100% OO, como ja foi citado, pela existencia de tipos primitivos, que nada mais sao do que “coisas” na linguagem que não são objetos. Numa linguagem 100% OO, tudo deveria ser um objeto - nao necessariamente filho de Object, mas um objeto mesmo assim. Se Java fosse 100% OO, nao teria problema algum em se fazer uma classe qualquer que estende int, ou algo do genero.
A razao pela qual se decidiu nao usar objetos no lugar de tipos primitivos foi bem pratica: é (ou pelo menos era, na epoca) muito dificil implementar uma maquina virtual com uma performance decente sem tipos primitivos, ja que o processador sabe trabalhar muito bem com ints, longs, floats e cia ltda.
Caso vc queira dar uma olhada em linguagens 100% OO, comece por Smalltalk, depois de uma olhada em Ruby, IO e va explorando daí. Eh uma viagem bem interessante de se fazer, pq nao so de Java vive esse mundinho
:arrow: http://www.iolanguage.com/SampleCode.html :
[code]Account := Object clone
Account balance := 0
Account deposit := method(v, balance = balance + v)
Account withdraw := method(v, balance = balance - v)
Account show := method(
write(“Account balance: $”, balance, "
")
)
myAccount := Account clone
myAccount show
"Depositing $10
" print
myAccount deposit(10)
myAccount show[/code]
Olá
Concordo com o Richard Peder e acho as discussões sobre formalidade muito boas para uma mesa de bar, na prática só dão grana para os professores. Mas o CV tem razão, herança múltipla não é pré-requisito para ser OO.
Vou divagar mais um pouco e jogar um longo blá, blá, blá sobre o assunto. De passagem mato um outro tópico já discutido em outra pasta sobre programar OOP com C.
Formalmente hoje, para ser considerada OOP, a linguagem precisa implementar os 4 conceitos básicos de abstração, encapsulamento, herança e polimorfismo (*). Sob este aspecto um programa Java pode ser escrito usando 100% OOP. Mas quando alguém usa somente classes estáticas e programa de modo apenas estruturado é quase certo que violará um ou mais dos conceitos básicos. Considerar que a existência de tipos nativos viola OOP é ser muito rigoroso pois Java só os aceita dentro de classes.
Agora um pouco de história de OOP relendo Bjarne Stroustrup que criou o C++.
Muitos ainda acham que apenas adotar os dois conceitos fundamentais de classe e objeto já é suficiente para uma linguagem ser considerada como orientada a objetos. Mas em 1986, em um artigo intitulado “What is OOP”, Bjarne Stroustrup chamava de “data abstraction” o modo de programar com tipos definidos pelo usuário. Para ser OOP era preciso implementar o conceito de herança. Neste artigo ao comparar o que o C++ precisava evoluir para se igualar a outras linguagens ele listou especificamente: tipos parametrizados (templates do C++ posterior, generics do próximo Java), exceções e herança múltipla. Mais tarde o C++ passou a admitir estas 3 coisas (**).
Do capítulo 1.2 Programming Paradigms do livro “The C++ Programming Language”, Bjarne Stroustrup, 2ndEd.1992, [list]OOP é uma técnica de programação - um paradigma para escrever “bons” programas para um conjunto de problemas. O termo linguagem orientada a objeto não significa nada além do que a linguagem provê os mecanismos que suportem o estilo orientado a objeto de programar bem.
Há uma importante distinção aqui. A linguagem é dita suportar um estilo de programação se provê facilidades que tornam conveniente (razoavelmente fácil, seguro e eficiente) usar este estilo. Uma linguagem não suporta a técnica se exige esforço ou habilidade excepcional para escrever tais programas. Por exemplo, você pode escrever programas estruturados em Fortran e programas orientados a objetos em C, porém isto é desnecessariamente difícil pois estas linguagens não suportam diretamente estas técnicas.[/list]
Os conceitos traduzidos acima não dizem nada sobre o que a linguagem deve suportar ou não para ser uma OOP. Mas já excluem todas as linguagens como C, Fortran, Assembler e outras que não contém as facilidades OOP.
No livro “The Design and Evolution of C++” de 1994, Stroustrup conta a história toda do C++ desde que começou com pré compiladores que ajeitavam o C para ficar mais ou menos OOP. Quando entra no C++ chama a atenção para uma das facilidades mais importantes para fazer OOP. Ele tomou emprestado do Simula o conceito de função virtual. Nem vou me estender aqui sobre isto, mas chamo a atenção que isto em Java é absolutamente fundamental. Todos os métodos em Java são virtuais com exceção dos estáticos, privados ou finais ( que não usam dynamic method lookup).
Por fim uma deliciosa definição de objeto tirada do Manual de referência do C++ de 1991, item r.3.7 Lvalues:
“An object is a region of storage”
Eu complementaria com minha definição de classe e objeto:
Classe é uma definição de um tipo que diz o que ele é e o que pode fazer (ou ser feito com ele). Ela pode existir no seu editor de texto ou no papel. Objeto é a representação desta definição que só existe na memória primária ou secundária de um computador.
(*) Programação Orientada ao Objeto: uma abordagem didática, Revista da Unicamp, Mário Leite e Nelson Abu Sanra Rahal Júnior
(**) Java sempre teve exceptions, a herança múltipla é propositadamente limitada e tipos parametrizados (generics) é uma das principais novidades do j2sdk 1.5.
[]s
Luca
javascript tudo eh publico nao eh? nao ha encapsulamento. e da pra herdar em javascript? polimorfismo? se for assim php tambem eh OO, e eu nao concordo. nao tem encapsulamento nem polimorfismo, apesar de haver “heranca”.
E tudo publico, sim, mas ate ai isso nao dita o encapsulamento. Encapsulamento nao precisa ser uma coisa embutida na linguagem, enquanto nao da pra ficar sem polimorfismo e heranca diretamente na linguagem. Python tambem eh OO (assim como JS, nao 100% OO), e nao tem encapsulamento explicito, tambem - voce dita que os membros sao publicos ou privados em Python prefixando os nomes das coisas com _, __, ___. Yuck.
Dita o encapsulamento sim, porque ja era o encapsulamento. Se eh tudo publico, quebra encapsulamento, fazendo de js e php nao ser nem um pouco OO. Tirando do artigo que o luca colocou, pode ver faicilmente que tudo public quebra o encapsulamento:
python tem encapsulamento, ai fica ok, pq voce pode impedir o cara de acessar suas variaives diretamente. php e js nao tem maneira alguma, nem gambiarra.
ps: muito bem escrito esse artigo da unicamp
[quote=“Paulo Silveira”]javascript tudo eh publico nao eh?[/code]
Negativo, variaveis locais não são, é assim que voce implementa membros private
Da sim! usa cascateamento de prototipos.
Claro que tem, não existe o contrario, early binding.
JS é OO sim, diferente do java, mas é.