isso quer dizer que se eu estou programando em java, eu estou utilizando Orientacao a Objetos???
Java só trabalha com progrmacao Orientada a Objetos?
43 Respostas
Olá
Em princípio sim. Qualquer programa em Java é orientado a objetos. Mas na prática você poderia escrever um programa com uma única classe cheia de métodos do mesmo jeito que a gente programava de forma estruturada lá pelos idos dos anos 90.
[]s
Luca
Essa é a idéia, mas vc pode escrever um programa só no main(), vai ficar um lixo mas o teu código naum pode ser considerado OO, OO nada mais é do q a reutilização de código, se vc usou Delphi, programava em OO só q naum sabia (talvez) pois o Delphi faz tudo sozinho, em java vc é q tem q fazer essas coisas. Mas a princípio java só trabalho com OO 
Não, programar java não significa programar orientado a objetos.
Orientaçao a objetos é uma forma de programar onde voce cria as classes
e essas classes trabalham em conjunto para realizar a tarefa.
Você pode programar tudo em uma única classe e ai seu programa
vai ser procedural sem orientaçao alguma.
Vai ficar horrível mas funciona, em alguns casos.
Olá
Eu ainda acho que é um pouco radical responder não porque toda a API Java é orientada a objetos. Mesmo que a gente escreva uma porcaria de programa macarrônico de uma classe só ele ainda de alguma forma será orientado a objetos (não sei porque lembrei do thinlet).
Mas aqui no GUJ a gente vem sempre discutindo questões relativas a boas práticas e tentando divulgar dicas coletadas em bons livros. A maioria das aplicações OO quase sempre tem trechos de códigos que descambam para código estruturado. Mas as vantagens da OO são enormes pois permitem abordar problemas que antes eram praticamente impossíveis de serem abstraídos. Falo por experiência própria porque desde 1969 quando escrevi meu primeiro programa já passei por todas as metodologias.
[]s
Luca
Concordo, Luca.
Programar em java de forma estruturada é programar BASEADO em objetos, como em vbscript (bleargh).
Você não precisa de uma linguagem OO para programar OO
Você não rpecisa de uma linguagem estruturada para programar de forma estruturada
Você pode usar OOD (Design Orientado a Objetos) com uma linguagem que não é orientada a objetos, como o C. Isso é feito na própria biblioteca-padrão do C (<stdio.h> tem a struct FILE, que é usada como se fosse um objeto.)
FILE *f = fopen ("teste.txt", "w");
fprintf (f, "Hello, 2 + 2 = %d\n", x + y);
fclose (f);
No código acima, teríamos uma instância do “objeto” FILE retornada pela função fopen. Essa instância é usada pelos métodos fprintf e fclose.
Você pode usar programação estruturada clássica com uma linguagem que é orientada a objetos, como o Java. Basta fazer todos seus métodos estáticos, e suas variáveis estáticas e públicas.
public class HelloOldWorld {
public static int x = 2;
public static int y = 2;
public static void main(String[] args) {
System.out.printf ("Hello, 2 + 2 = %d! %n", x + y);
}
}
A linguagem ajuda, mas não é tudo. Pense o que você faz com a língua portuguesa e o que um poeta como o Fernando Pessoa faz com a língua portuguesa.
Só não concordo com o trecho acima, pois Orientação a Objetos não é uma forma de programar e sim um paradigma, uma forma de entender as situações reais e transformá-las em objetos com caractríticas encapsuladas e ações para modificá-la.
Sim, OO é um paradigma, baseado neste paradigma você tem uma forma de programar que pode ser aplciada em qualquer (!) linguagem.
Olá
Sempre que alguém diz isto cita o FILE. Mas nunca ninguém cita nenhuma outra coisa. Eu não concordo que se possa usar OOD com C sem forçar muito a barra. As tabelas de símbolos não foram preparadas para isto, o compilador não ajuda em nada. Os resultados serão pífios.
Mas como exemplo teórico foi bem lembrado.
[]s
Luca
OláSempre que alguém diz isto cita o FILE. Mas nunca ninguém cita nenhuma outra coisa.
Que tal as bibliotecas do GTK?
Eu acho que a partir do momento que qualquer classe que você crie
HERDE de Object, já temos aí pelo menos um príncipio de OO.
Agora se você vai utilizar bem a OO é outra história.
Mas Java oferece todas as ferramentas pra modelagem OO.
Outra biblioteca em C puro que é meio (mas não muito) “orientada a objetos” é o OpenSSL. Só que ela depende muito de macros e outras coisas, e convenhamos que até eu descobrir que ela era “orientada a objetos” eu pastei um pouco.
É claro que em C é realmente difícil ter programação orientada a objetos de uma forma simples - antigamente era usado o CFront, um compilador que gerava código C (terrivelmente ilegível) a partir do C++. Isso quer dizer que o C não é, em termos práticos, muito adequado para programação orientada a objetos.
Forçando a barra :twisted: :
Object-oriented programming in C
outro
Object Oriented Programming in C
Olá
:twisted::twisted::twisted:
Um desafio para quem quiser me provar que isto é viável em termos práticos: pegar um programinha open source qualquer em Java ou em C++e reescreve-lo usando C. Pode ser o JBoss mas eu sugiro o tomcat por que até livro tem sobre seu fonte
[]s
Luca
Trabalhar com Java de modo procedural não tem vantagens, pois o forte do Java é a OO. A oo como todos sabem, traz vários beneficios se comarada a programação procedural:
Modularidade;
Escalabilidade;
Manutenção mais fácil;
Coerência, entre outros.
Um abraço.
<blockquote><div class="quote-author">Marcio_Nogueira:</div>Trabalhar com Java de modo procedural não tem vantagens, pois o forte do Java é a OO. A oo como todos sabem, traz vários beneficios se comarada a programação procedural:
Modularidade;
Escalabilidade;
Manutenção mais fácil;
Coerência, entre outros.
Um abraço.
Discordo de vc.
OO em 99% dos casos é sim a melhor escolha e traz inumeras vantagens.
Mas nao 100% dos casos.
O que seria esse 1% que deve ser feito em procedural?
Um ‘sistema’ de 4 tabelas desenvolvido com uma ferramenta RAD pra Java.
A não ser que vc considere uma instância de uma classe só com gets e sets, sem nenhuma logica, um objeto. Se for isso ai sim, java so trabalha orientado a objetos.
Ué, é o que?
Até concordo que um JFrame com um monte de métodos dentro de uma única classe possa parecer procedural, mas pra mim só o fato de você criar uma String e manipular ela já está trabalhando com objetos.
Vamos concordar que procedural em Java ninguém faz… eu acho né…
Aqui tem um livro em pdf gratuito sobre OO em Ansi C
http://www.planetpdf.com/developer/article.asp?ContentID=object_orientated_programming_&gid=6635
Outro dia eu tive essa inspiração:
#include <stdio.h>
struct {
struct {
int (*println) (const char *);
} out;
} System = { { puts } };
int main (void){
System.out.println("ola mundo");
return 0;
}
Apesar do código acima não ser nada mais do que uma estrutura com um ponteiro para uma função, é esse o mecanismo usado pelo C para prover métodos aos objetos. Com o uso de algumas macros é possivel fazer chover :)
Lua faz a mesma coisa: vc usa orientação a objetos atraves de metatabelas
http://montegasppa.blogspot.com/2007/02/orientao-objetos-em-lua.html
http://kodumaro.blogspot.com/2007/03/herana-mltipla-em-lua.html
A não ser que vc considere uma instância de uma classe só com gets e sets, sem nenhuma logica, um objeto.
Ué, é o que?
Até concordo que um JFrame com um monte de métodos dentro de uma única classe possa parecer procedural, mas pra mim só o fato de você criar uma String e manipular ela já está trabalhando com objetos.
Vamos concordar que procedural em Java ninguém faz… eu acho né…
rs… eu queria concordar com vc que ninguem faz nada procedural em Java, mas infelizmente faz… e eu sou 1 deles que fazia muito… só agora depois de 2 anos de exp com Java que estou conseguindo finalmente aplicar os conceitos de OO e desfrutar de suas vantagens.
Mas perceba:
- “Java só trabalha com Objetos” : é uma coisa
- “Java só trabalha com Programação Orientada a Objetos” : é outra coisa completamente diferente
Java tem objetos e, também, tipos primitivos (int, char, float).
É, realmente…
Mas continuo pensando que não é só porque tá tudo em uma classe ou tudo dentro de um main() que não seja OO, alguma coisa ali no meio da bagunça será…
Acho que dá pra programar em Java usando o paradigma funcional, como em lisp, sem nenhum estado ‘aparente’, mas nunca tentei fazer, não sei se conceitualmente é possivel.
OO é um paradigma. Isto todo mundo sabe! Mas criar implementações de código utilizando este paradigma é muito complicado e a linguagem de programação que está sendo utilizada deve prover estes recursos.
Falar que dá pra programar OO em C ansi, para mim, é uma bobagem sem tamanho. Alguns de vocês vão ficar chateados e vão colocar "kilos" de links para sites e livros que dizem o contrário. Mas... alguém é capaz de implementar um código simples como este utilizando C ou Pascal ou qualquer outra linguagem procedural:
class A {
int varA = 0;
int getA() {
return varA;
}
int setA(int varA) {
this.varA = varA;
}
}
class B extends A {
int getA() {
return varA + 1;
}
int getA(int i) {
return varA + i;
}
}
Pode até ser que vocês consigam implementar algo que dê um resultado parecido, mas não é OO. É só um "gato"!
Com relação a utilizar Java ou outra linguagem OO de forma procedural é uma verdade. É claro que o usuário terá que fazer uso de alguns Objetos externos do seu programa, mas não quer dizer que o código que ele está escrevendo está orientado a objetos!
Só o fato de se escrever um método que executa várias operações que poderiam (e deveriam) ser "quebradas" em vários outros métodos já é considerado um programação procedural. Mas não é só isso. Isto é somente um dos motivos....
Para programar OO nós devemos seguir TUDO o que manda as teorias de OO. Mas no "mundo real" isto é quase impossível. Agente sempre peca em alguma coisa. Portanto não confunda uma linguagem que dê suporte a OO (como o Java e o C++) com um código escrito seguindo as recomendações de OO.
Bom inviável é re-escrever o JBoss ou o Tomcat, não é um pouco exagerado, afinal eu te desafio a re-escrever o tomcat em SmalTalk (que tambem é OO)
você levaria um bom tempo, logo provavelmente não o faria.
se pararmos pra pensar o compilador do java e a JVM também são programas que provavelmente não foram escritos em linguagens OO, logo é plenamente possível fazer qualquer coisa feita em Java em C
e digo mais qualquer software que você fez em toda a sua vida poderia ser feito em Assembler 
Quero ver quem faz o Tomcat ou o JBoss em Assembler… hehehehehe
Eu tambem 
mas não é impossivel ; )
Opa, basta plugar sua nuca na Matrix e começar a codificar…
Eu só fiz aqueles programinhas bem idiotas em Assembler (tipo pra limbar o MBR do HD, huauahuahauh), nem imagino o que exista além disso… 
Java é orientado a objetos, mas ainda é uma programação estruturada, pois você tem estruturas de iteração, de controle e de seleção.
OO é um paradigma. Isto todo mundo sabe! Mas criar implementações de código utilizando este paradigma é muito complicado e a linguagem de programação que está sendo utilizada deve prover estes recursos.Falar que dá pra programar OO em C ansi, para mim, é uma bobagem sem tamanho. Alguns de vocês vão ficar chateados e vão colocar “kilos” de links para sites e livros que dizem o contrário. Mas… alguém é capaz de implementar um código simples como este utilizando C ou Pascal ou qualquer outra linguagem procedural:
…
Pode até ser que vocês consigam implementar algo que dê um resultado parecido, mas não é OO. É só um “gato”!
Putz, que porcaria: Java não têm suporte à SQL! Não dá pra programar com sets de dados relacionais em Java então. Quer dizer, eu posso até utilizar aqueles Resultsets JDBC da vida mas não, é um ‘gato’.
Putz, Java não tem o conceito de ContaCorrente embutido na linguagem! Eu posso até utilizar uma classe para mapear este conceito mas vai ser um’ gato’.
Ironia à parte, a coisa é simples: não é porque uma linguagem não suporta um conceito que não pode trabalhar com ele. Fazemos isso o tempo todo. A diferença entre OOP em uma linguagem dita OO e uma não é que a dita OO tem os conceitos do domínio ‘objetos’ dentro dela. Um bom modo de aprender sobre como uma linguagem pdoe ser adaptada é estudar CLOS, o modelod e Objetos de Common Lisp que é implementado em cima do Common List, procedural e quase-funcional.
Putz, que porcaria: Java não têm suporte à SQL! Não dá pra programar com sets de dados relacionais em Java então. Quer dizer, eu posso até utilizar aqueles Resultsets JDBC da vida mas não, é um ‘gato’.Putz, Java não tem o conceito de ContaCorrente embutido na linguagem! Eu posso até utilizar uma classe para mapear este conceito mas vai ser um’ gato’.
Hã?!?!?! :?
Acredito que você não entendeu bem o que eu disse, então leia novamente o meu texto e tente implementar aquele exemplo meu acima em uma linguagem não OO como C ansi ou Pascal. Vai lá…
O que eu quis dizer foi exatamente isso. Uma linguagem que não “tem os conceitos … dentro dela”, como você disse, não dá para se trabalhar orientado a objetos. Dá para se fazer um gato para se ter um resultado parecido, mas não é a mesma coisa.
Se fosse assim a Bell Labs não teria desenvolvido o C++ e a Borland não teria desenvolvido o Delphi! =]
Ai é questão de ponto de vista 
Quer implementar seu exemplo em C? Crie uma estrutura e funções à la get/set. Pronto (o uso de ponteiros void para fazer blur nas referências às structs ajuda).
get/set faz aquilo ser um objeto? Não, da mesma maneira que sua ausência também não faz ser uma estrutura de dados simples. O que faz um ou outro é o modelo de programação. Pascal ou C não possuem classes? IO e JavaScript também não e são linguagens OO. OO é um conceito implementável em praticamente qualquer linguagem.
Vamos lá:
1 - Não é porque Java não tem Hashes integrados à sintaxe como PERL ou Ruby que eu não posso utilizar Hashes. Só dá mais trabalho porque não disponho dos recursos facilitadores mas posso modelar meus Hashes com classes (como HashMap).
2 - Não é porque C/Pascal não têm suporte à classes e objetos na linguagem que não posso utilizar objetos. Só dá mais trabalho porque não disponho das facilidades mas posso implementar o conceito com estruturas e funções trabalhando de maneira disciplinada (com uma ajuda de macros).
Pergunto: Dado que (1) é verdade por que (2) não seria?
O que eu quis dizer foi exatamente isso. Uma linguagem que não “tem os conceitos … dentro dela”, como você disse, não dá para se trabalhar orientado a objetos. Dá para se fazer um gato para se ter um resultado parecido, mas não é a mesma coisa.Se fosse assim a Bell Labs não teria desenvolvido o C++ e a Borland não teria desenvolvido o Delphi! =]
A primeira versão de C++ era apenas syntax sugar para C, ela estendia a linguagem para dar a ilusão de que existiam classes e objetos mas o código gerado que era compilado, OO, era, olha só, o bom e velho C.
Uma coisa é o conceito de OO outra coisa é uma linguagem OOP. Um não implica no outro.
Quer implementar seu exemplo em C? Crie uma estrutura e funções à la get/set. Pronto (o uso de ponteiros void para fazer blur nas referências às structs ajuda).get/set faz aquilo ser um objeto? Não, da mesma maneira que sua ausência também não faz ser uma estrutura de dados simples.
Não sei se você percebeu, mas com aqueles exemplos eu implementei os conceitos de Herança, polimorfismo e encapsulamento da OO. Os get/set foram só pra facilitar na hora de montar o exemplo, mas se você quiser eu posso mudar o nome! =]
Eu quero que alguem monte uma estrutura desta. Herança, polimorfismo e encapsulamento usando C ou Pascal.
Primeiramente JavaScript não é e nunca foi linguagem de programação. Ele é uma linguagem script! =]
E pra que você saiba, ele permite sim a criação de classes e objetos. Mas ele não implementa todos os conceitos de OO. Herança por exemplo não dá para fazer com JavaScript.
Vamos lá:1 - Não é porque Java não tem Hashes integrados à sintaxe como PERL ou Ruby que eu não posso utilizar Hashes. Só dá mais trabalho porque não disponho dos recursos facilitadores mas posso modelar meus Hashes com classes (como HashMap).
2 - Não é porque C/Pascal não têm suporte à classes e objetos na linguagem que não posso utilizar objetos. Só dá mais trabalho porque não disponho das facilidades mas posso implementar o conceito com estruturas e funções trabalhando de maneira disciplinada (com uma ajuda de macros).
Pergunto: Dado que (1) é verdade por que (2) não seria?
Vamos lá:
1- O que Hash tem a ver com a história?!
2- Estas “facilidades” a que se refere são exatamente os recursos que a linguagem oferece para se trabalhar OO. E “o conceito com estruturas e funções trabalhando de maneira disciplinada” que você também se refere é exatamente o gato. Você pode até conseguir um resultado parecido, mas não é OO!
A primeira versão de C++ era apenas syntax sugar para C, ela estendia a linguagem para dar a ilusão de que existiam classes e objetos mas o código gerado que era compilado, OO, era, olha só, o bom e velho C.Uma coisa é o conceito de OO outra coisa é uma linguagem OOP. Um não implica no outro.
Pois é… era tão bom funcionando desta maneira que eles acabaram soltando outras versões posteriormente para realmente poder implementar OO, visto que só a extensão (leia-se gato) não supria as reais necessidades para se programar em OO.
Mas… como o Peczenyj sabiamente falou…
Ai é questão de ponto de vista ;-)
=]
Aí que você se engana. Não sei se você percebeu (posso indicar alguns livros sobre OO que tratam do tema para esclarecimentos posteriores) mas get/set (getters e setters, acessores e mutatores, whatever) não garante encapsulamento e por isso seu exemplo não necessariamente está encapsulado. Smalltalk não têm get/set, teria Smalltalk encapsulamento?
Leia isso:
http://blog.fragmental.com.br/2006/03/04/fowler-e-getters/
Acho que você tem uns problemas conceituais aí. Vamos bem devagar para que entendas:
1 - Linguagens de Script são linguagens de programação, JavaScript é uma linguagem de programação. Ruby também. PERl também. PHP também.
2 - JavaScript possui OO baseada em protótipos, não em classes. Classes não são necessárias para ter OO: http://www.google.com/search?q=javascript+prototype+oop Essa diferença que você não está entendendo e por não entendê-la você está achando estes ‘problemas’ de herança em JavaScript. Herança com protótipos é feita copiando um objeto-pai. Quando você tem tipagem dinâmica isso é altamente equivalente à herança em tipagem estática como você está acostumado em Java.
Deixa eu adivinhar: você não conhece PERL nem Ruby. Acertei?
Hashes nestas linguagens são conceitos implícitos na sintaxe da linguagem. Algo assim:
a = {'chave1' => 'valor', 'chave2'=> 'valor2'}
Em java não são implícitos na sintaxe da linguagem. Eu não tenho hashes em Java então? Tenho. O código acima em Java poderia ser:
Map a = new hashMap();
a.put("chave1", "valor1");
a.put("chave2", "valor2");
Note que não existe o conceito de hash na sintaxe da linguagem mas eu crio o conceito de hash utilizando uma classe. Da mesma maneira quando uma linguagem não possui o conceito de classe em sua sintaxe eu posso emulá-lo de outra forma. java tem objetos que representam hashes e C pode ter funções e estruturas que representam objetos.
E por que não éOO? Por favor, vamos lá: referência sou argumentos. Tem três mensagens que você está dfalando ‘não é OO’ sem jsutificar, o que é OO?
Não senhor. As ‘necessidades’ eram supridas, apenas se optou por criar uma outra linguagem em vez de estender C. Por favor, consulte as referências.
Não é questão de ponto de vista, é questão de conhecer e saber diferenciar um conceito da implementação do conceito. Como falie posso passar algumas referências para consulta.
Aí que você se engana. Não sei se você percebeu (posso indicar alguns livros sobre OO que tratam do tema para esclarecimentos posteriores) mas get/set (getters e setters, acessores e mutatores, whatever) não garante encapsulamento e por isso seu exemplo não necessariamente está encapsulado. Smalltalk não têm get/set, teria Smalltalk encapsulamento?O Jovem... eu já disse, só usei o nome get/set para ficar mais fácil na hora de escrever. Mas se você prefere, segue codigo modificado:Leia isso:
class A {
int varA = 0;
int joao() {
return varA;
}
int maria(int varA) {
this.varA = varA;
}
}
class B extends A {
int joao() {
return varA + 1;
}
int joao(int i) {
return varA + i;
}
}
Agora você consegue perceber os conceitos de OO?! Agora você poderia implementar para mim este código em C?!
Acho que você tem uns problemas conceituais aí. Vamos bem devagar para que entendas:1 - Linguagens de Script são linguagens de programação, JavaScript é uma linguagem de programação. Ruby também. PERl também. PHP também.
2 - JavaScript possui OO baseada em protótipos, não em classes. Classes não são necessárias para ter OO: http://www.google.com/search?q=javascript+prototype+oop Essa diferença que você não está entendendo e por não entendê-la você está achando estes 'problemas' de herança em JavaScript. Herança com protótipos é feita copiando um objeto-pai. Quando você tem tipagem dinâmica isso é altamente equivalente à herança em tipagem estática como você está acostumado em Java.
1- Com relação ao JavaScript ser uma linguagem de programação ou não, mais ainda do que o paradigma de OO, isto é uma questão de ponto de vista. Não vou discordar de você que JavaScript é uma linguagem de programação.
2- Em momento nenhum eu disse que acho que JavaScript é orientado a objetos. Aliás, não acho! Eu disse que ele não implementa todas as características de OO.
Deixa eu adivinhar: você não conhece PERL nem Ruby. Acertei?Hashes nestas linguagens são conceitos implícitos na sintaxe da linguagem. Algo assim:
a = {'chave1' => 'valor', 'chave2'=> 'valor2'}Em java não são implícitos na sintaxe da linguagem. Eu não tenho hashes em Java então? Tenho. O código acima em Java poderia ser:
Map a = new hashMap(); a.put("chave1", "valor1"); a.put("chave2", "valor2");Note que não existe o conceito de hash na sintaxe da linguagem mas eu crio o conceito de hash utilizando uma classe. Da mesma maneira quando uma linguagem não possui o conceito de classe em sua sintaxe eu posso emulá-lo de outra forma. java tem objetos que representam hashes e C pode ter funções e estruturas que representam objetos.
Volto a perguntar:
O que hash tem a ver com a história?! =/
E por que não éOO? Por favor, vamos lá: referência sou argumentos. Tem três mensagens que você está dfalando 'não é OO' sem jsutificar, o que é OO?
E tem três mensagens que você está dizendo que é OO sem justificar. Como já disse (tem três mensagens), o fato de conseguir montar uma estrutura em uma linguagem que forneça um resultado semelhante ao de uma linguagem realmente OO, para mim (e por isto é uma questão de ponto de vista), não quer dizer que você está desenvolvendo OO. É um gato! OU se você preferir, POG.
Volto a pedir, implemente o código besta que eu escrevi acima usando C ou Pascal. Se tem todo este esquema de estruturas e tudo que você falou antes, então quer dizer há como implementar o código.
Não senhor. As 'necessidades' eram supridas, apenas se optou por criar uma outra linguagem em vez de estender C. Por favor, consulte as referências.
Claro. É bem mais fácil implementar uma linguagem totalmente nova do que extender uma antiga!
Não é questão de ponto de vista, é questão de conhecer e saber diferenciar um conceito da implementação do conceito. Como falie posso passar algumas referências para consulta.
Este é o seu ponto de vista! =]
O Jovem... eu já disse, só usei o nome get/set para ficar mais fácil na hora de escrever. Mas se você prefere, segue codigo modificado:
Menos ironia. Leia os artigos se quiser tentar argumentar porque você está se repetindo mesmo tendo sido contestado. Você pode chamar de get/set, laCongaSexy/casaDaMaeJoana, nao importa.
class A { int varA = 0; int joao() { return varA; } int maria(int varA) { this.varA = varA; } } class B extends A { int joao() { return varA + 1; } int joao(int i) { return varA + i; } }Agora você consegue perceber os conceitos de OO?! Agora você poderia implementar para mim este código em C?!
Nossa, quanta arrogância. pena que você não leu o que te passei para evitar ficar gastando bytes no banco de dados se repetindo ad eternum com argumentos...err... não-exatamente-corretos.
Encapsulamento não é esconder variáveis privadas. leia os links que passei e descubra porque, não vou continuar discutindo com a parede sobre este ponto, quem seguir o link e ler os dois textos vai perceber que seu argumento não é válido porque isso não é encapsulamento. De qualquer forma, sabia que isso é uma convenção? Sabia que nada me impede de acessar diretamente o atributo privado via reflection? Sabia que eu só não faço porque não quero quebrar as convenções de modificadores de acesso? Da mesma forma uma struct em C pode ser """""encapsulada""""" (note as trocentas aspas, isso não é encapsulamento!) via acessores e mutatores. Ah, mas eu posso fazer umc ast e chamar o membro da struct diretamente! Se fizer isso eu quebro as conveções que estabeleci da mesma forma que faria utilizando reflection para setar uma tributo privado.
1- Com relação ao JavaScript ser uma linguagem de programação ou não, mais ainda do que o paradigma de OO, isto é uma questão de ponto de vista. Não vou discordar de você que JavaScript é uma linguagem de programação.2- Em momento nenhum eu disse que acho que JavaScript é orientado a objetos. Aliás, não acho! Eu disse que ele não implementa todas as características de OO.
...
Volto a perguntar:
O que hash tem a ver com a história?! =/
...
Vou interpretar isso como um "não entendi, não quero entender e tenho raiva de quem entende" e ignorar seus comentários repetitivos e já respondidos.
E tem três mensagens que você está dizendo que é OO sem justificar.
Não senhor, eu justifiquei, inclusive com exemplos e comparações.
Como já disse (tem três mensagens), o fato de conseguir montar uma estrutura em uma linguagem que forneça um resultado semelhante ao de uma linguagem realmente OO, para mim (e por isto é uma questão de ponto de vista), não quer dizer que você está desenvolvendo OO. É um gato! OU se você preferir, POG.
Antes de acusar algo que você não conhece de ser POG ou não seria legal procurar entender ao menos o que é Orientação a Objetos para ao menos conseguir responder perguntas simples.
Volto a pedir, implemente o código besta que eu escrevi acima usando C ou Pascal. Se tem todo este esquema de estruturas e tudo que você falou antes, então quer dizer há como implementar o código.
Eu já disse lá em cima: crie uma função que receba uma struct e returne um inteiro e chame ela de get_alguma_coisa e crie uma função que receba uma struct e um inteiro e chame ela de set_alguma_coisa. Não me venha dizer que o fato do receptor ser especificado como parâmetro não é OO porque assim você tira CLOS das linguagens/plataformas OO.
Claro. É bem mais fácil implementar uma linguagem totalmente nova do que extender uma antiga!
Ahm?
Bom, está mais que óbvio que você está confundindo implementação (OOP em Java, linguagens baseadas em classes...) com conceitos (OO) e não quer sequer procurar referências para entender que OO é um conceito implementado de diversas maneiras. Sinto muito mas eu, Fowler(Um Distilled, POEAA e trezentos papers), Stroustrup (criador do C++), Alan Kay (Smalltalk), Peter Seibel (hacker CLOS), Meyer (criador de CBD e provavelmente o autor mais completo sobre OOP), Anders Helsberg (criador de C# e Delphi) e mais toda a referência mínima básica de OO discordamos de você.
Não, não é apenas o meu ponto de vista e você deveria reservar um tempinho para a leitura.
dmarcosm,
olha só, como eu acho o pcalcado um entre vários aqui do GUJ que postam aqui para agregar conhecimento e não pra falar besteira, vou te mostrar o programinha em C com conceitos OO. Deu uma meia hora pra fazer.
Aqui o arquivo structs.h
#ifndef _STRUCTS_H
#define _STRUCTS_H
#include <stdlib.h>
#ifdef __cplusplus
extern "C" {
#endif
/* Atributos e métodos da Classe A */
/* Propriedades */
struct tA {
int varA;
};
/* Construtor */
void init_A(struct tA* pttA) {
pttA->varA = 0;
};
/* Getter */
int A_getVarA(struct tA* pttA) {
return pttA->varA;
};
/* Setter */
void A_setVarA(struct tA* pttA, int varA) {
pttA->varA = varA;
};
/* Destrutor */
void delete_A(struct tA** ptpttA) {
free(*ptpttA);
*ptpttA = 0;
};
/* Atributos e métodos da Classe B */
/* Propriedades */
struct tB {
struct tA super;
};
/* Construtor */
void init_B(struct tB* pttB) {
init_A(&(pttB->super));
};
/* Getters */
int B_getVarA(struct tB* pttB) {
struct tA* pttA = (struct tA*) pttB;
return pttA->varA + 1;
};
int B_getVarAAdd(struct tB* pttB, int i) {
struct tA* pttA = (struct tA*) pttB;
return pttA->varA + i;
};
/* Destrutor */
void delete_B(struct tB** ptpttB) {
free(*ptpttB);
*ptpttB = 0;
};
#ifdef __cplusplus
}
#endif
#endif
e aqui um main que usa a definição acima:
#include <stdio.h>
#include <stdlib.h>
#include "structs.h"
/*
*
*/
int main(int argc, char** argv) {
/* Vou iniciar um objetoA */
struct tA objectA;
init_A(&objectA);
/* Vou dar um get no varA no objetoA */
printf("objetoA.varA = %d\n", A_getVarA(&objectA));
/* Vou setar o objetoA */
A_setVarA(&objectA, 17);
printf("objetoA.varA = %d\n", A_getVarA(&objectA));
/* Vou criar um objetoB */
struct tB objectB;
init_B(&objectB);
/* Como um objetoB é um objetoA, vou chamar o setter da superclasse */
A_setVarA((struct tA*)&objectB, 43);
/* Vou chamar o getter do objetoB, lembre-se que adiciona 1 */
printf("objetoB.varA = %d\n", B_getVarA(&objectB));
/* Vou chamar o segundo getter do objetoB */
printf("objetoB.varA(12) = %d\n", B_getVarAAdd(&objectB, 12));
/* Vou atribuir o objetoB a uma referência ao objetoA */
struct tA* referenceA = &objectB;
/* vou chamar o getter do objeto A */
printf("referenceA.varA = %d\n", A_getVarA(referenceA));
return (0);
}
Por favor, não se prenda a sintaxe. Repare que existe polimorfismo, herança e encapsulamento (ainda que getter e setter é um jeito porco de encapsular) como um paradigma orientado a objetos deve ter.
E aí, ainda acha que é impossível fazer isso em C?
Ai é questão de ponto de vista ;-)
Para discutir o assunto de forma séria, vc teria que seguir um caminho mais científico usando, por exemplo, as ideas de Popper sobre uma teoria só ter valor científico se ela for refutável, e o teste de uma teoria se dá no que ela proíbe, não no que ela permite. Dizer que OO em Ansi C é um gato e que ‘não é a mesma coisa’ é apenas ponto de vista, sem nenhum fundamento além do que a pessoa acha.
Abraços
dmarcosm,olha só, como eu acho o pcalcado um entre vários aqui do GUJ que postam aqui para agregar conhecimento e não pra falar besteira, vou te mostrar o programinha em C com conceitos OO. Deu uma meia hora pra fazer.
Aqui o arquivo structs.h
#ifndef _STRUCTS_H #define _STRUCTS_H #include <stdlib.h> #ifdef __cplusplus extern "C" { #endif /* Atributos e métodos da Classe A */ /* Propriedades */ struct tA { int varA; }; /* Construtor */ void init_A(struct tA* pttA) { pttA->varA = 0; }; /* Getter */ int A_getVarA(struct tA* pttA) { return pttA->varA; }; /* Setter */ void A_setVarA(struct tA* pttA, int varA) { pttA->varA = varA; }; /* Destrutor */ void delete_A(struct tA** ptpttA) { free(*ptpttA); *ptpttA = 0; }; /* Atributos e métodos da Classe B */ /* Propriedades */ struct tB { struct tA super; }; /* Construtor */ void init_B(struct tB* pttB) { init_A(&(pttB->super)); }; /* Getters */ int B_getVarA(struct tB* pttB) { struct tA* pttA = (struct tA*) pttB; return pttA->varA + 1; }; int B_getVarAAdd(struct tB* pttB, int i) { struct tA* pttA = (struct tA*) pttB; return pttA->varA + i; }; /* Destrutor */ void delete_B(struct tB** ptpttB) { free(*ptpttB); *ptpttB = 0; }; #ifdef __cplusplus } #endif #endife aqui um main que usa a definição acima:
#include <stdio.h> #include <stdlib.h> #include "structs.h" /* * */ int main(int argc, char** argv) { /* Vou iniciar um objetoA */ struct tA objectA; init_A(&objectA); /* Vou dar um get no varA no objetoA */ printf("objetoA.varA = %d\n", A_getVarA(&objectA)); /* Vou setar o objetoA */ A_setVarA(&objectA, 17); printf("objetoA.varA = %d\n", A_getVarA(&objectA)); /* Vou criar um objetoB */ struct tB objectB; init_B(&objectB); /* Como um objetoB é um objetoA, vou chamar o setter da superclasse */ A_setVarA((struct tA*)&objectB, 43); /* Vou chamar o getter do objetoB, lembre-se que adiciona 1 */ printf("objetoB.varA = %d\n", B_getVarA(&objectB)); /* Vou chamar o segundo getter do objetoB */ printf("objetoB.varA(12) = %d\n", B_getVarAAdd(&objectB, 12)); /* Vou atribuir o objetoB a uma referência ao objetoA */ struct tA* referenceA = &objectB; /* vou chamar o getter do objeto A */ printf("referenceA.varA = %d\n", A_getVarA(referenceA)); return (0); }Por favor, não se prenda a sintaxe. Repare que existe polimorfismo, herança e encapsulamento (ainda que getter e setter é um jeito porco de encapsular) como um paradigma orientado a objetos deve ter.
E aí, ainda acha que é impossível fazer isso em C?
Caracas… acho q vocês não estão lendo o que eu escrevi. NUNCA disse que é impossível, NUNCA disse que não dá pra fazer e NUNCA disse que não se pode fazer.
A ÚNICA coisa que eu disse é que, o que as pessoas fazem para ter um resultado parecido em uma linguagem não OO é um gato, ou se preferirem, um Workaround! Ainda mais… disse que este é o meu ponto de vista. Isto é igual a discussão do ovo e da galinha!!!
Você disse que gastou 30 minutos pra fazer aquele exemplo idiota que eu gastei 2 minutos. E ainda por cima nem usei uma IDE, escrevi direto no editor aqui do fórum!!! É exatamente por isto que eu falo que é um gato. Não é nativo. Não é da linguagem.
Agora vai implementar só as entidades do projeto do qual eu participo. São 95 classes só na camada de entidade!!! Fora a camada de persistência, negócio e apresentação. Sem contar as classes utilitárias DAOs e Formatadores! Se agente gastar 1 ano para desenvolver isto em Java, vocês gastariam 15 para desenvolver em C ansi orientado a objetos, certo?
Teoria != Prática
Ps.: Pcalçado, sim! Eu lí os links que você passou.
E…
- Stroustrup desenvolveu o C++ (o C ansi foi desenvolvido pelo Ritchie). Ele achava que C não era suficiente para implementar OO eficientemente! =] Ele criou o “C with classes” que inicialmente agregava o conceito de classes ao C (por isto o nome). Posteriormente, com a adição de novos recursos, o nome foi alterado para C++.
- Smalltalk 80 é completamente OO. O 72 por exemplo ainda não implementava muito bem estes conceitos não.
- Sobre Martin Fowler, tenho que admitir que não li todos os livros dele, mas acredito que quando por ventura ele resolve usar um exemplo de OO, não usa C ansi!!!
- Quanto aos outros, bem… acho que eles quiseram desenvolver linguagens OO, porque as não OO não eram muito úteis para este fim!!!
- Ah… e o Hejlsberg desenvolveu o C# baseado, olhem só, em Java e C++!!!
- Já o Delphi utiliza uma linguagem chamada “Object Pascal” que, a pesar de ser baseada, não é o mesmo que Pascal. Esta sim, é orientada a objetos.
Quanto aos links… bem… acho que é só você dar uma pausa para reler aquilo que você já leu!
Ele implementou… 
Er… acho que quem precisa reler o que escreveu é você mesmo:
OO é um paradigma. Isto todo mundo sabe! Mas criar implementações de código utilizando este paradigma é muito complicado e a linguagem de programação que está sendo utilizada deve prover estes recursos.Falar que dá pra programar OO em C ansi, para mim, é uma bobagem sem tamanho. Alguns de vocês vão ficar chateados e vão colocar “kilos” de links para sites e livros que dizem o contrário. Mas… alguém é capaz de implementar um código simples como este utilizando C ou Pascal ou qualquer outra linguagem procedural:
Para programar OO nós devemos seguir TUDO o que manda as teorias de OO. Mas no “mundo real” isto é quase impossível. Agente sempre peca em alguma coisa. Portanto não confunda uma linguagem que dê suporte a OO (como o Java e o C++) com um código escrito seguindo as recomendações de OO.
Aliás, se para ter um programa OO você precisa utilizar todos os conceitos que estão sob o guarda-chuva OO você não pode dizer que um programa Java o é porque ele têm não-objetos como tipos primitivos.
É engraçado ler isso sem (1) nenhum argumento que o justifique (2)você ter sequer explicado o que seria ‘ser OO’ para você.
Se existe uma ferramenta OO por que ele usaria uma não OO? Qual seu ponto?
'Acho" parece ser um bom sumário para os seus tópicos. Novamente recomendo um pouco de leitura para entender as coisas antes de comentar.
Logo…?
Na verdade faz um bom tempo que a linguagem se chama Delhpi Language mas não entendi seu ponto.
Acho que talvez você não tenha entendido o ponto fundamental:
- Ao contrário do que você disse é sim possível desenvolver OO em uma linguagem não OO
- Dado que existe uma linguagem OO que pode ser utilizada não existem muitos motivos para se produzir software OO em uma linguagem que não esta
Você disse que é besteira, nós dissemos que não e mostramos porquê. Simples assim.
Ah, e se não dá para programar OO em C não dá pra programar em AOP com Java. Simples assim.