É, quando eu estava fazendo a SofiaIA, estava meio chateado com o fato da engine física e gráfica terem, cada uma, sua própria classe de vetores. Aí eu ia entrar com meu toolkit de IA, e teria que incluir uma terceira classe dessas…
Então, vi aí uma possíbilidade de trabalhar com a minha classe internamente, enquanto deixava o usuário usar as dele de maneira externa, de maneira muito mais transparente.
[quote=tnaires][quote=marciosantri][code]type
TClassePai = class(TInterfacedObject) // Ao invés de herdar de TObject, herdar de TInterfacedObject
…
…
end;
TClasseFilha = class(TClassePai, IInterface)
…
…
end;[/code]
Qual o problema nisso?
[/quote]
Do ponto de vista prático, não há nenhum problema. O que o chun tá questionando - e eu concordo com ele - são as limitações que você é obrigado a tratar porque a linguagem impõe.
Se você tem, por exemplo, a seguinte hierarquia:
Em Java ficaria:
[code]class Animal {
}
class Peixe extends Animal implements Nadador {
}[/code]E em Delphi:
TAnimal = class(TInterfacedObject);
TPeixe = class(TAnimal, INadador);Veja que, no caso do Delphi, você tem uma classe de domínio acoplada a um conceito estranho ao mesmo.[/quote]
Certo. Em Java realmente é mais prático. Mas, como o Chun diz em sua assinatura, não precisamos cortar os pulsos por causa disto no Delphi. Nunca tive esse problema todo que ele cita e nem me sinto limitado por causa disto. Pra falar a verdade, comparando com herança propriamente dita, o uso de interfaces é muito baixo. Eu não vejo essa necessidade toda.
Inté.
[quote=marciosantri][quote=tnaires][quote=marciosantri][code]type
TClassePai = class(TInterfacedObject) // Ao invés de herdar de TObject, herdar de TInterfacedObject
…
…
end;
TClasseFilha = class(TClassePai, IInterface)
…
…
end;[/code]
Qual o problema nisso?
[/quote]
Do ponto de vista prático, não há nenhum problema. O que o chun tá questionando - e eu concordo com ele - são as limitações que você é obrigado a tratar porque a linguagem impõe.
Se você tem, por exemplo, a seguinte hierarquia:
Em Java ficaria:
[code]class Animal {
}
class Peixe extends Animal implements Nadador {
}[/code]E em Delphi:
TAnimal = class(TInterfacedObject);
TPeixe = class(TAnimal, INadador);Veja que, no caso do Delphi, você tem uma classe de domínio acoplada a um conceito estranho ao mesmo.[/quote]
Certo. Em Java realmente é mais prático. Mas, como o Chun diz em sua assinatura, não precisamos cortar os pulsos por causa disto no Delphi. Nunca tive esse problema todo que ele cita e nem me sinto limitado por causa disto. Pra falar a verdade, comparando com herança propriamente dita, o uso de interfaces é muito baixo. Eu não vejo essa necessidade toda.
Inté.[/quote]
Hehehe… boa…
A vantagem do uso de interfaces é sempre estar programando independentemente da implementação, isso é muito legal em qualquer sistema… pois com isso , se alguem tem uma ideia nova , ou descorda de algo… pode “implementar aquilo da forma que achar melhor”…
ex:
LinkedList
ArrayList
Ambas implementao a interface List… só que uma é uma lista encadeada e outra uma lista dentro de um array…
Cada qual com suas caracteristicas… mas são listas 
Constumo utilizar interfaces em tudo onde posso , a API de Java INTEIRA é feito assim…
prefiro muito mais um:
List lista = new LinkedList();
do que:
LinkedList lista = new LinkedList();
"
[quote=marcosalex]
TAnimal = class;
TPeixe = class(TAnimal, INadador);
Não precisa “queimar” a herança no pai.
[/quote]
Não precisa, mas nesse seu exemplo você terá que escrever suas próprias versões dos métodos QueryInterface, _AddRef e _Release que já estão implementadas em TInterfacedObject, conforme falei anteriormente.
Existe SourceCode deste TInterfacedObject?
[quote=ViniGodoy]Na verdade, o C++ tem um conceito de interfaces ainda mais abstrato, se levar em consideração o uso de templates.
Com templates, você pode definir uma interface unicamente pelo contrato, e deixar que o C++ crie ou não aquele método, caso a interface atenda o contrato. Não há necessidade de uma classe abstrata ou interface.
Por exemplo, o método abaixo funciona para qualquer coisa que tenha o operador > definido:
[code]
//Mytype deve ser uma classe com o operador de > definido
template
myType Maximum (myType a, myType b) {
return (a>b?a:b);
}[/code]
Quando eu digo qualquer coisa, quero dizer, numeros:
int x = Maximum(10, 20);
Quero ou uma classe:
BigDecimal x = Maximum(BigDecimal(10), BigDecimal(20));
Note que o código acima restringe a interface única e exclusivamente a:
a) Presença ou não do operador de >
b) Comentário explicando o que esse sinal deveria fazer!
E tudo isso é verificado em tempo de compilação. E notem também que isso é infinitamente mais poderoso que os generics, que o povo insiste em dizer que é “a mesma coisa que templates”.[/quote]
Templates me lembra como a vida é curta pra perder tempo aprendendo C++. Neste caso é utilizado pra gerar codigo em tempo de compilação. Coisa que em linguagens lazy ou dinâmica com suporte a macros lisp fazem o trabalho de forma infinitamente mais simples.
Todas as linguagens mencionadas pelo autor do tópico são OO. Mas algumas delas são tão arcaicas e complicadas que não vejo motivo pra se preocupar com elas hoje em dia. Apesar do conceito de OO ser o mesmo cada linguagem o implementa de maneira diferente e IMO linguagens como C++ são um péssimo exemplo de projeto de linguagem OO.
Existe, procure na unit System. Se estiver com o Delphi aberto, clique no nome da classe segurando a tecla Ctrl.
O que eu acho mais engraçado, é que você produz críticas sem fundamento. Essas linguagens são arcaicas pelo fato de até hoje serem padrão para desenvolvimento de tecnologia. Tente contestar a INTEL, SUN, Microsoft, CISCO, Apple, Adobe, Corel…
Muito tempo depois… até tinha esquecido deste tópico. 
É que caiu em uma prova para uma vaga que estava concorrendo.
Achei estranho pq pelo que eu sabia todas suportam OO…
Mas lembro que escolhi DELPHI, mas tinha certeza q este tb era… hauahauhaahu
Valeu galera…
Abraços
Wanderson 
[quote=juliocbq]
O que eu acho mais engraçado, é que você produz críticas sem fundamento. Essas linguagens são arcaicas pelo fato de até hoje serem padrão para desenvolvimento de tecnologia. Tente contestar a INTEL, SUN, Microsoft, CISCO, Apple, Adobe, Corel…[/quote]
Sério que todas essas empresas usam C++ como “padrão” de desenvolvimento?
Alguém precisa te dizer, C != C++.
[quote=ViniGodoy]
E tudo isso é verificado em tempo de compilação. E notem também que isso é infinitamente mais poderoso que os generics, que o povo insiste em dizer que é “a mesma coisa que templates”.[/quote]
Os únicos que ouvi até hoje compararem generics com templates foram programadores C++. Além do mais templates nada mais é do que uma gambiarra para uma linguagem mal projetada. Desnecessário dizer que Lisp faz isso e muito mais.
Se você precisa trabalhar com C++, paciência. Mas fazer apologia dessa merda, pelo amor de Deus. Eu trabalho com Java, mas reconheço que Java, a linguagem e não a plataforma, é uma merda.
[quote=mochuara]
Templates me lembra como a vida é curta pra perder tempo aprendendo C++. Neste caso é utilizado pra gerar codigo em tempo de compilação. Coisa que em linguagens lazy ou dinâmica com suporte a macros lisp fazem o trabalho de forma infinitamente mais simples.[/quote]
Amém.
[quote=mochuara][quote=juliocbq]
O que eu acho mais engraçado, é que você produz críticas sem fundamento. Essas linguagens são arcaicas pelo fato de até hoje serem padrão para desenvolvimento de tecnologia. Tente contestar a INTEL, SUN, Microsoft, CISCO, Apple, Adobe, Corel…[/quote]
Sério que todas essas empresas usam C++ como “padrão” de desenvolvimento?
Alguém precisa te dizer, C != C++.[/quote]
E qual das que eu citei usam c?
[quote=Thiagosc][quote=ViniGodoy]
E tudo isso é verificado em tempo de compilação. E notem também que isso é infinitamente mais poderoso que os generics, que o povo insiste em dizer que é “a mesma coisa que templates”.[/quote]
Os únicos que ouvi até hoje compararem generics com templates foram programadores C++. Além do mais templates nada mais é do que uma gambiarra para uma linguagem mal projetada. Desnecessário dizer que Lisp faz isso e muito mais.
Se você precisa trabalhar com C++, paciência. Mas fazer apologia dessa merda, pelo amor de Deus. Eu trabalho com Java, mas reconheço que Java, a linguagem e não a plataforma, é uma merda.[/quote]
não fala o que você não conhece e nem nunca usou.
Melhor você provar o porquê de templates ser essa palavra que citou, do que falar coisas sem fundamento, como, “simplesmente é assim”.
[quote=juliocbq]
não fala o que você não conhece e nem nunca usou.
Melhor você provar o porquê de templates ser essa palavra que citou, do que falar coisas sem fundamento, como, “simplesmente é assim”.[/quote]
Macros em lisp são processadas e compiladas antes do tempo de execução e não há limites do que você pode fazer, pois todos os recursos da linguagem estão lá. Você pode criar objetos, métodos, funções, gerar código e lógica baseada parâmetros passados pelo usuário.
Ou seja, pode-se fazer tudo com uma sintaxe simples sem impacto algum de performance.
C++ é um lixo. Em pensar que existem milhares de regrinhas toscas e limitações de sintaxe para lhe fornecer 1/100 da flexibilidade e do poder que qualquer linguagem decente dá chega a ser ridículo.
Precisa trabalhar com esse lixo? Azar o seu.
A linguagem C é muito mais simples (e tosca), mas cumpre o papel de “assembly portável”. Qual é o papel de C++? C++ é apenas uma abominação. Pessoas que não conhecem nada melhor são suas principais vítimas.
Obs.: Eu mencionei listas de parâmetros recursivas das macros? Onde pode-se passar uma árvore de objetos e eles são automaticamente desestruturados e ligados a seus respectivos símbolos? Não, né. Aí já seria humilhação demais para os fãs de C++ , coitados.
[quote=Thiagosc][quote=juliocbq]
não fala o que você não conhece e nem nunca usou.
Melhor você provar o porquê de templates ser essa palavra que citou, do que falar coisas sem fundamento, como, “simplesmente é assim”.[/quote]
Macros em lisp são processadas e compiladas antes do tempo de execução e não há limites do que você pode fazer, pois todos os recursos da linguagem estão lá. Você pode criar objetos, métodos, funções, gerar código e lógica baseada parâmetros passados pelo usuário.
Ou seja, pode-se fazer tudo com uma sintaxe simples sem impacto algum de performance.
C++ é um lixo. Em pensar que existem milhares de regrinhas toscas e limitações de sintaxe para lhe fornecer 1/100 da flexibilidade e do poder que qualquer linguagem decente dá chega a ser ridículo.
Precisa trabalhar com esse lixo? Azar o seu.
A linguagem C é muito mais simples (e tosca), mas cumpre o papel de “assembly portável”. Qual é o papel de C++? C++ é apenas uma abominação. Pessoas que não conhecem nada melhor são suas principais vítimas.
Obs.: Eu mencionei listas de parâmetros recursivas das macros? Onde pode-se passar uma árvore de objetos e eles são automaticamente desestruturados e ligados a seus respectivos símbolos? Não, né. Aí já seria humilhação demais para os fãs de C++ , coitados.[/quote]
Melhor você prestar atenção no que está dizendo, esses macros também estão presentes em c++. Sobre o papel de c++ não pergunte para mim, pergunte para a Adobe, Corel, Apple, Intel, Sun, CISCO, Microsoft… e lá vai mais um monte, para não dizer que todas usam c++ como padrão de desenvolvimento. Pergunte para eles.
Leia sobre preprocessadores e #define.
Não estou aqui para discutir a melhor linguagem de programação, até porque no meu trabalho, eu tenho poder de escolha, e não preciso ficar me agarrando a marketing para conseguir fatia de mercado.
Desculpem desviar o assunto do tópico, mas já que estamos falando de Lisp…
Para o Thiagosc ou qualquer outro usuário: desculpem a ignorância mas os dialetos do Lisp, como Scheme e Clojure, também possuem esse sistema de macros? Em sua opinião, qual o melhor dialeto de Lisp para se aprender hoje em dia? Clojure é uma boa escolha?
"
Eu também mexi com Scheme quando meu professor passou como trabalho de final de semestre escrever um programa que calculasse a derivada de uma função (!). E tive um contato muito breve com Haskell, tão breve que nem me lembro mais como é.
Clojure perde em alguma coisa para todos esses dialetos?