Migracao delphi para java

Atualmente estamos mudando um CRM em Delphi para Java, estamos usando 100% Ajax para parecer que o usuário continue em uma aplicação Desktop.

Sim so podemos usar as analises e a base teve muitas modificações.
na verdade o sistema teve de ser refeito por completo.

abraço

Isso é relativamente comum até, o que vc não deve tentar fazer é apenas converter código, use a documentação disponível (caso exista) para fazer novamente o seu sistema.

Cara jah migrei sistemas relativamente simples… e mesmo esses relativamente simples foi aproveitado muito pouco mesmo…

No meu caso o motivo da migração foi compatibilidade com linux,
porem foi um decisão não muito experta pois existe meios de fazer o sistema
.exe rodar em linux.

abraço

Atualmente estamos migrando e o que posso te dizer é o seguinte:

• Muita coisa terá que ser refeita. Vc pode até manter sua estrutura de objetos mas como as coisas são feitas internamente são diferentes.
• Vc vai sofrer por estar acostumado com o RAD da IDE do Delphi (se a aplicação for Desktop). No começo vc xinga o Java de tudo que é nome, não entende por que uma p**** dessas vem tão sem opções para desktop. Aí vc começa a desenvolver seus objetos ou achar exemplos na net e coisa começa a melhorar. Mas até lá vc perde um bom tempo…
• Exige mais máquina para compilar e executar. Mas nada que uma memoriazinha extra não resolva, hehehe.
• Vai tentar procurar funcionalidades no Delphi que não existem no Java por que são feitas de outra maneira (o Timer, por exemplo).
• Nas suas pesquisas vc vai ver um monte de coisa legal que o Java tem pronta só para baixar e usar. Isso não se acha no Delphi…
• Depois de tudo isso vc estará programando no Java.

Existem softwares para migrar de Delphi para Java. Eu até achei uns na época, mas são pagos. Mas se aceita um conselho, sem essa de conversão. Aprenda a tecnologia que vc vai bem mais longe.
É o mesmo que tentar converter um sistema Clipper para Delphi… Como dizia um amigo meu “isso não vai dar certo…” (sessão nostalgia).

marciosantri:

- Vc vai sofrer por estar acostumado com o RAD da IDE do Delphi (se a aplicação for Desktop). No começo vc xinga o Java de tudo que é nome, não entende por que uma p**** dessas vem tão sem opções para desktop. Aí vc começa a desenvolver seus objetos ou achar exemplos na net e coisa começa a melhorar. Mas até lá vc perde um bom tempo…

Sempre a desculpa esfarrapadas dos objetos…porque é mais chique, mais OO… como se o Delphi não tivesse isso!!

Comparar facilidade de java e delphi no desktop é piada, não é não? Escrever código (e muito) pra desenhar tela??? Dá licença que eu tenho mais o que fazer…

Pela sua indignação eu imagino que seja algo do tipo baixar uma IDE atual e parar de programar em notepad.

renato3110:

marciosantri:

- Vc vai sofrer por estar acostumado com o RAD da IDE do Delphi (se a aplicação for Desktop). No começo vc xinga o Java de tudo que é nome, não entende por que uma p**** dessas vem tão sem opções para desktop. Aí vc começa a desenvolver seus objetos ou achar exemplos na net e coisa começa a melhorar. Mas até lá vc perde um bom tempo…

Sempre a desculpa esfarrapadas dos objetos…porque é mais chique, mais OO… como se o Delphi não tivesse isso!!

Comparar facilidade de java e delphi no desktop é piada, não é não? Escrever código (e muito) pra desenhar tela??? Dá licença que eu tenho mais o que fazer…

Concordo que no Delphi é mais fácil. No Java, depois de um tempo a gente aprende a se virar. A diferença é q o Delphi traz muito mais coisa pronta (nível Desktop). O NetBeans melhorou bastante e tem promessas de mais melhorias. Nada mal para um ferramenta free. O q não podemos é ficar preso ao passado, pois o Delphi infelizmente já está. Então, mãos à obra e fazer as coisas funcionarem ao invés de ficar reclamando. Já passei dessa fase.

Sem dúvida criar interfaces para Desktop em Java é mais trabalhoso. Mas acredito que não possamos colocar a culpa somente nele mas principalmente na inexistência de uma ferramenta - pelo menos tao boa como a IDE do Delphi - que possibilite agilidade na construção de aplicativos Desktop. Será que esta deficiência não seria justificada pelo domínio WEB no mercado de desenvolvimento Java ? :?

alex@ander:

Sem dúvida criar interfaces para Desktop em Java é mais trabalhoso. Mas acredito que não possamos colocar a culpa somente nele mas principalmente na inexistência de uma ferramenta - pelo menos tao boa como a IDE do Delphi - que possibilite agilidade na construção de aplicativos Desktop. Será que esta deficiência não seria justificada pelo domínio WEB no mercado de desenvolvimento Java ? :?

Pela sua indignação eu imagino que seja algo do tipo baixar uma IDE atual e parar de programar em notepad.

Tá bom, a IDE escreve pra você, mas still there is a code…

A minha raiva é quando falam que swing é lindo, e que tela montada em código é lindo, porque é cool, porque é OO. Ironicamente, os prórpios criadores das IDEs, ao contrário de seus usuários religiosos, estão mudando os conceitos, mesmo que 10 anos atrasado…

Ahm? E sua sugestão é trocar código pelo que?

Pô, você num já programou em Delphi? Não lembra?

Vc deve ser foda em java ne, nunca teve que aprender do zero. Toda migração e muito complicada…

O Netbeans, do jeito que está hoje já é melhor que o delphi. Mas se for portabilidade em sistemas pascal, porque não recompilaram com o lazarus e freepascal, que já é 100% compatível com o delphi? Reescrever o sistema para web, na minha opinião é apenas para se adequar a tendências.

http://www.lazarus.freepascal.org/

Já passei por esta situação algumas vezes.

Em todas elas topei com o seguinte problema: a lógica de negócio estava embutida quase que inteiramente nos formulários. E units eram criadas apenas para incluir uma ou outra função de uso mais geral.

No início, é difícil, porque basicamente você vai tentar programar em Java como fazia em Delphi: e vai dar errado (é o comportamento mais comum que observei)
No entanto, após a segunda tentativa, você começa a se acostumar com a OO (apesar de Delphi ser orientado a objetos, as pessoas costumam se esquecer disto (principalmente os Delpheiros)) e, numa boa? É um aprendizado fascinante apesar do stress que você vai passar com outras pessoas que possam estar bitoladas com Delphi.

Vc deve ser foda em java ne, nunca teve que aprender do zero. Toda migração e muito complicada…

:shock: Você re-encarnou um tópico que faz mais de 2 anos pra dizer isso?

heheh Também tinha observado isso.

De qualquer forma, é uma discussão interessante das experiências com programas legados.

Participei de migração Delphi pra Java em duas empresas e é sempre do jeito que o pessoal falou aqui. Onde estou atualmente, ainda conseguimos uma transição mais suave migrando o servidor de aplicação de Delphi+sockets pra Java+Jboss+soap.

Mas só funcionou porque o pessoal já desenvolvia separando as regras de negócios da interface. Mesmo que não era uma coisa 100%, mas ajudou no projeto.

marcosalex:

heheh Também tinha observado isso.

De qualquer forma, é uma discussão interessante das experiências com programas legados.

Participei de migração Delphi pra Java em duas empresas e é sempre do jeito que o pessoal falou aqui. Onde estou atualmente, ainda conseguimos uma transição mais suave migrando o servidor de aplicação de Delphi+sockets pra Java+Jboss+soap.

Mas só funcionou porque o pessoal já desenvolvia separando as regras de negócios da interface. Mesmo que não era uma coisa 100%, mas ajudou no projeto.

Li o tópico desdo inicio e tbm achei a discusão interessante, porém o objetivo do Delphi e o do Java são diferente em questão de programação, delphi é mais voltado a ser produtivo.
E o java podemos dizer que é voltado a um conceito diferente de programação, a sua idéia de OO, tem como objetivo construir programas muito mais complexos dos que os feitos em Delphi.

Obs: EU sei que delphi tbm é OO, mais com a IDE dele vc praticamente se nega a existência do OO.

PAULOSJR:

marcosalex:

heheh Também tinha observado isso.

De qualquer forma, é uma discussão interessante das experiências com programas legados.

Participei de migração Delphi pra Java em duas empresas e é sempre do jeito que o pessoal falou aqui. Onde estou atualmente, ainda conseguimos uma transição mais suave migrando o servidor de aplicação de Delphi+sockets pra Java+Jboss+soap.

Mas só funcionou porque o pessoal já desenvolvia separando as regras de negócios da interface. Mesmo que não era uma coisa 100%, mas ajudou no projeto.

Li o tópico desdo inicio e tbm achei a discusão interessante, porém o objetivo do Delphi e o do Java são diferente em questão de programação, delphi é mais voltado a ser produtivo.
E o java podemos dizer que é voltado a um conceito diferente de programação, a sua idéia de OO, tem como objetivo construir programas muito mais complexos dos que os feitos em Delphi.

Obs: EU sei que delphi tbm é OO, mais com a IDE dele vc praticamente se nega a existência do OO.

As duas ferramentas servem para desenvolver o mesmo tipo de software. E só porque a linguagem é java, isso não quer dizer que pode construir softwares mais complexos que em pascal. O problema do delphi é o suporte a ferramenta, que a borland não dá mais.

Por que a IDE nega a existência do OO?

Cara disse isso pq difícilmente vc ver alguém criando uma classe, etc.

Eu comecei a programar em Delphi sem ao menos saber oque era uma classe.

Você clica em um Objeto da aba aperta F11, vai em nome e digita um nome.

Você não se preocupa com nada. você programa com Objetos, da pra dizer que o delphi é um editor de programas uehaueahuehauea

Mais não estou dismerecendo ele, uso delphi e muito.
Delphi foi concerteza uma grande evolução para programação.

Não disse que vc não pode criar coisas mais complexas em delphi.

Mais concerteza vc nunca vai usar delphi para fazer um software complicado, e quando digo complicado não estou falando de um aplicativo de desktop grande.

Sabe: chega a ser ridículo o modo como as pessoas reduzem o Delphi a um mero lego.

Comentários do tipo “em Java eu faço coisas complexas, em Delphi faço formulários” ou “Delphi é uma ferramenta de produtividade, enquanto Java é OO” são tão comuns que há momentos nos quais eu me pergunto se quem as diz REALMENTE sabe do que está falando…

kicolobo:

Sabe: chega a ser ridículo o modo como as pessoas reduzem o Delphi a um mero lego.

Comentários do tipo “em Java eu faço coisas complexas, em Delphi faço formulários” ou “Delphi é uma ferramenta de produtividade, enquanto Java é OO” são tão comuns que há momentos nos quais eu me pergunto se quem as diz REALMENTE sabe do que está falando…

Com certeza. Temos dois projetos em delphi aqui. Na época tínhamos duas opções para desenvolvê-lo. Ou c++ ou Object Pascal com o delphi. Como ferramenta o delphi era muito mais produtivo que visual studio. Java não servia porque era um software para processar video em realtime. Então escolhemos o delphi.

http://images.google.com.br/imgres?imgurl=http://loja.tray.com.br/loja/img_prod_temp/139993/180_1119_1.jpg&imgrefurl=http://loja.tray.com.br/loja/produto-[telefone removido]-placa_de_captura_citrox_cx4016_dvr_16_canais_120_fps&usg=__DYcJF534vxf2TLUWROimqdSvTo4=&h=180&w=180&sz=4&hl=pt-BR&start=26&um=1&tbnid=N4pciRHFw8i4DM:&tbnh=101&tbnw=101&prev=/images%3Fq%3Dcftv%2Bcitrox%26ndsp%3D20%26hl%3Dpt-BR%26sa%3DN%26start%3D20%26um%3D1

Sabem, continuando o meu raciocínio, a impressão que tenho ao ouvir bobagens do tipo “Java para coisas complexas e Delphi para formulários” é a de que existe “linguagem para ser competente” e “linguagem para ser morcego”, ou seja, é um dos papos mais furados que já vi.

Só pra lembrar, Skype é feito em Delphi (pelo menos era o caso mais famoso)

kicolobo:

Já passei por esta situação algumas vezes.

Em todas elas topei com o seguinte problema: a lógica de negócio estava embutida quase que inteiramente nos formulários. E units eram criadas apenas para incluir uma ou outra função de uso mais geral.

No início, é difícil, porque basicamente você vai tentar programar em Java como fazia em Delphi: e vai dar errado (é o comportamento mais comum que observei)
No entanto, após a segunda tentativa, você começa a se acostumar com a OO (apesar de Delphi ser orientado a objetos, as pessoas costumam se esquecer disto (principalmente os Delpheiros)) e, numa boa? É um aprendizado fascinante apesar do stress que você vai passar com outras pessoas que possam estar bitoladas com Delphi.

Foi basicamente o que aconteceu comigo, quando comecei a aprender o programa nascia com uma tela na minha lógica, depois de aprender OO, hoje primeiro penso em classes e relacionamentos e só depois que penso em qualquer outra coisa (acesso ao banco por exemplo, isso é uma coisa que delphero sempre pensa antes de tudo).

laudenpower:

kicolobo:

Já passei por esta situação algumas vezes.

Em todas elas topei com o seguinte problema: a lógica de negócio estava embutida quase que inteiramente nos formulários. E units eram criadas apenas para incluir uma ou outra função de uso mais geral.

No início, é difícil, porque basicamente você vai tentar programar em Java como fazia em Delphi: e vai dar errado (é o comportamento mais comum que observei)
No entanto, após a segunda tentativa, você começa a se acostumar com a OO (apesar de Delphi ser orientado a objetos, as pessoas costumam se esquecer disto (principalmente os Delpheiros)) e, numa boa? É um aprendizado fascinante apesar do stress que você vai passar com outras pessoas que possam estar bitoladas com Delphi.

Foi basicamento o que aconteceu comigo, quando comecei a aprender o programa nascia com uma tela na minha lógica, depois de aprender OO, hoje primeiro penso em classes e relacionamentos e só depois que penso em qualquer outra coisa (acesso ao banco por exemplo, isso é uma coisa que delphero sempre pensa antes de tudo).

Olha, tem e eu já vi. Acredito que o código gerado nesses casos é muito pior que delphi, mas acho que é a forma como os conceitos são passados, se todo programador delphi aplicasse os conceitos OO “na carne”, ia começar em java com bilhões de quilômetros de distância de qualquer novato em java.

kicolobo:

Sabem, continuando o meu raciocínio, a impressão que tenho ao ouvir bobagens do tipo “Java para coisas complexas e Delphi para formulários” é a de que existe “linguagem para ser competente” e “linguagem para ser morcego”, ou seja, é um dos papos mais furados que já vi.

Só pra lembrar, Skype é feito em Delphi (pelo menos era o caso mais famoso)

Amigo quando for postar em um forum poste sua opnião critica de forma construtiva, não tente ofender ou se sentir ofendido.

A idéia e trocar idéias.

Voltando a ideia do delphi, quantas vezes vc criou uma classe em delphi:

Uma coisa que vejo muito é nego falando puts, vou ter que alterar todos os forms da aplicação ae eu digo:
E pergunto se não tem como alterar o formulário padrao para que todos recebam como herança a mudança.

Como disse delphi não é uma péssima ferramente, só que a sua facilidade leva a ignorância, os cara sai apertando parafusos sem saber para que.

E sim em java vc faz coisas muito mais complexas que em delphi.

PAULOSJR:

kicolobo:

Sabem, continuando o meu raciocínio, a impressão que tenho ao ouvir bobagens do tipo “Java para coisas complexas e Delphi para formulários” é a de que existe “linguagem para ser competente” e “linguagem para ser morcego”, ou seja, é um dos papos mais furados que já vi.

Só pra lembrar, Skype é feito em Delphi (pelo menos era o caso mais famoso)

Amigo quando for postar em um forum poste sua opnião critica de forma construtiva, não tente ofender ou se sentir ofendido.

A idéia e trocar idéias.

Voltando a ideia do delphi, quantas vezes vc criou uma classe em delphi:

Uma coisa que vejo muito é nego falando puts, vou ter que alterar todos os forms da aplicação ae eu digo:
E pergunto se não tem como alterar o formulário padrao para que todos recebam como herança a mudança.

Como disse delphi não é uma péssima ferramente, só que a sua facilidade leva a ignorância, os cara sai apertando parafusos sem saber para que.

E sim em java vc faz coisas muito mais complexas que em delphi.

Paulinho,

não me senti agredido ou intencionei agredir ninguém (sinto muito se a carapuça lhe serviu).
Vamos dar uma relida no meu primeiro parágrafo para expor que minha crítica foi na realidade construtiva?

a impressão que tenho ao ouvir bobagens do tipo “Java para coisas complexas e Delphi para formulários” é a de que existe “linguagem para ser competente” e “linguagem para ser morcego”, ou seja, é um dos papos mais furados que já vi.

1. Por que é uma bobagem dizer coisas do tipo “Java para coisas complexas e Delphi para formulários” - porque o Object Pascal (agora se chama Delphi memso) é uma linguagem muito poderosa e que já foi usada inúmeras vezes no desenvolvimento de softwares críticos pelo mundo. O editor de formulários é apenas uma funcionalidade a mais que o ambiente de desenvolvimento Delphi apresenta.

Sendo assim, fica exposto que é tolice dizer que Delphi é apenas uma linguagem para montar formulários, o que é basicamente o que é dito aqui quando você lê posts nos quais as pessoas dizem coisas como “eu só monto o meu formulário e incluo a lógica de programação lá dentro”.

Logo, aqui apontei um erro, certo? Como se chama isto? Crítica construtiva! Por que construtiva? Por que estou direcionando alguém para o caminho correto da questão.

Agora, vamos para a segunda frase do meu post.
2. Só pra lembrar, Skype é feito em Delphi (pelo menos era o caso mais famoso)

Uau! Alguém aqui ficou decepcionado porque o Skype é feito em Delphi e não em Java ou C++? Se sim, sinto muito, não foi a intenção.

Quer fazer bonito pra alguém Paulinho? Comece tendo uma leitura crítica ok? Beijos.

Cara vc tem complexo.

Não estou tentando fazer bonito pra ngm, ao contrário de vc não acho que isso aqui seja uma vida de verdade.
Não estou tentando impressionar ngm.

Oque disse e se vc msm analizar oque escreveu vai ver 2que não disse nada construtivo

Normalmente oq vc vai usar para fazer esse programa é a documentação, se estiver atualizada (o que todo mundo sabe que quase nunca existe).
Mapeie todas as regras de negócio, telas, esquemas, banco e refaça todo ele pensando nas boas práticas, se tiver tabelas no BD inuteis ou utilizadas pra “gatos”, refaça desde o BD então e ve com um DBA se houver para ele migrar as informações sem perda.

[EDIT] Eu vi agora uma discussão em cima sobre Delphi e Java, seguinte o cara apenas quer saber como migrar então gente vamos manter o foco aqui, não existe pior nem melhor linguagem e sim pior e melhor programador, então sem discussões fora do contexto, por favor, vamos manter um nível e harmonia aqui. [/EDIT]

PAULOSJR:

kicolobo:

Sabem, continuando o meu raciocínio, a impressão que tenho ao ouvir bobagens do tipo “Java para coisas complexas e Delphi para formulários” é a de que existe “linguagem para ser competente” e “linguagem para ser morcego”, ou seja, é um dos papos mais furados que já vi.

Só pra lembrar, Skype é feito em Delphi (pelo menos era o caso mais famoso)

Amigo quando for postar em um forum poste sua opnião critica de forma construtiva, não tente ofender ou se sentir ofendido.

A idéia e trocar idéias.

Voltando a ideia do delphi, quantas vezes vc criou uma classe em delphi:

Uma coisa que vejo muito é nego falando puts, vou ter que alterar todos os forms da aplicação ae eu digo:
E pergunto se não tem como alterar o formulário padrao para que todos recebam como herança a mudança.

Como disse delphi não é uma péssima ferramente, só que a sua facilidade leva a ignorância, os cara sai apertando parafusos sem saber para que.

E sim em java vc faz coisas muito mais complexas que em delphi.

Como o que, por exemplo? Eu estou tentando entender o que se faz com java que não se faz em qualquer outra linguagem.

Já trabalhei em projetos desenvolvidos de forma totalmente procedural e também OO em Delphi.

Discordo que o Delphi seja uma ferramenta tipo lego para ignorantes de OO.

Mas também reconheço que a aplicação de OO e MVC não acontece de forma tão natural como em Java…

Em java, o próprio ambiente força (mas não impede totalmente) que o programa cresça em OO.

Em Delphi, dá para fazer. Mas a “tentação” está sempre perto…

Já vi projetos começarem corretos, mas por falta de pulso firme do lider, os datamodules começaram a proliferar como ervas daninhas, e logo logo as queries dentro dos formulários.

Já trabalhei em 8 empresas com Delphi, e em apenas uma eu acredito que o sistema possa ser classificado como projeto OO…

Os delpheiros gostam de componente (não todos). Afinal, querendo ou não, por mais que alguns não aceitem, foi a produtividade que popularizou o Delphi, e não a OO (embora ele possa ser OO).

E acredito que os poucos programas realmente OO em delphi existem apenas por causa do “heroísmo” de alguns bons programadores…

Isso porque a própria Embarcadero (e a Borland na época também…) continua focando na produtividade…

Tanto é que, até hoje, nas últimas versões, o Delphi não tem uma coisa, que EU pelo menos acredito que seria legal e um “incentivo” para usar OO com MVC:

Um grid que lê uma lista…

Até hoje isso não existe (até existe componentes de terceiros, mas não achei que ficou bom…).

Os grids do delphi estão presos a ler outros componentes de herdam de dataset (ou TDataset, para não ofender os delpheiros).

O problema disso que é o desenvolvimento acaba sendo mais fácil da forma “componentizada” (arrastar e soltar compomentes…).

Quando você começa a deselvolver uma aplicação MVC, começa bem, no Model, no Controller… Mas quando chega na View, esbarra com esse problema:

Você tem uma lista de objetos, seja pessoa, NF ou o que quer que seja… Mas o grid não lê a sua classe. O grid só lê herdeiros de TDataset… Daí então (já vi em mais de um lugar) o negócio que começou bonito, acaba com algumas (Deus me perdoe…) gambis para acoplar as camadas e ainda assim usar a TDBGrid …

Caso alguém tenha resolvido esse problema de forma “elegante”, me dê a dica…

Mas em fim:

Resumindo, dá para fazer coisas tão complexas quanto forem necessárias em Delphi sim.
Assim como em .NET também dá.
Assim como em outras linguagens também…

A única resalva é que, em cada uma, isso é feito de forma diferente.

MauroOliveira:

Já trabalhei em projetos desenvolvidos de forma totalmente procedural e também OO em Delphi.

Discordo que o Delphi seja uma ferramenta tipo lego para ignorantes de OO.

Mas também reconheço que a aplicação de OO e MVC não acontece de forma tão natural como em Java…

Em java, o próprio ambiente força (mas não impede totalmente) que o programa cresça em OO.

Em Delphi, dá para fazer. Mas a “tentação” está sempre perto…

Já vi projetos começarem corretos, mas por falta de pulso firme do lider, os datamodules começaram a proliferar como ervas daninhas, e logo logo as queries dentro dos formulários.

Já trabalhei em 8 empresas com Delphi, e em apenas uma eu acredito que o sistema possa ser classificado como projeto OO…

Os delpheiros gostam de componente (não todos). Afinal, querendo ou não, por mais que alguns não aceitem, foi a produtividade que popularizou o Delphi, e não a OO (embora ele possa ser OO).

E acredito que os poucos programas realmente OO em delphi existem apenas por causa do “heroísmo” de alguns bons programadores…

Isso porque a própria Embarcadero (e a Borland na época também…) continua focando na produtividade…

Tanto é que, até hoje, nas últimas versões, o Delphi não tem uma coisa, que EU pelo menos acredito que seria legal e um “incentivo” para usar OO com MVC:

Um grid que lê uma lista…

Até hoje isso não existe (até existe componentes de terceiros, mas não achei que ficou bom…).

Os grids do delphi estão presos a ler outros componentes de herdam de dataset (ou TDataset, para não ofender os delpheiros).

O problema disso que é o desenvolvimento acaba sendo mais fácil da forma “componentizada” (arrastar e soltar compomentes…).

Quando você começa a deselvolver uma aplicação MVC, começa bem, no Model, no Controller… Mas quando chega na View, esbarra com esse problema:

Você tem uma lista de objetos, seja pessoa, NF ou o que quer que seja… Mas o grid não lê a sua classe. O grid só lê herdeiros de TDataset… Daí então (já vi em mais de um lugar) o negócio que começou bonito, acaba com algumas (Deus me perdoe…) gambis para acoplar as camadas e ainda assim usar a TDBGrid …

Caso alguém tenha resolvido esse problema de forma “elegante”, me dê a dica…

Mas em fim:

Resumindo, dá para fazer coisas tão complexas quanto forem necessárias em Delphi sim.
Assim como em .NET também dá.
Assim como em outras linguagens também…

A única resalva é que, em cada uma, isso é feito de forma diferente.

O que acontece é que o foco dos problemas acaba sendo o framework e o desenho deles. Os componentes também são classes, então não diria que usá-los não seja OO. O que diferencia Object Pascal de Java, é que escreveram um framework como o hibernate para java. O hibernate fez tanto sucesso que o mesmo foi implementado em c#. Os componentes não estão atrelados ao formulário, Você pode instanciá-los em qualquer outra classe e acessá-los, ou usar um componente próprio para isso, como o DatabaseForm, dessa forma diminuindo o acoplamento.

O que eu percebi dos profissionais que conheci, que usavam delphi, era que nenhum sabia programar, nem mesmo um pouquinho. Isso porque o delphi era tão fácil de usar que acabava, qualquer pessoa sem conhecimento se tornando programador.

Eu trabalhei muito tempo com Delphi e nao tenho medo de dizer que ele é terrivel. É OO? pode até ser, mas…

E a erro de referencia circular? Se a classe A referencia a classe B, entao a classe B nao pode referenciar a classe A, e dá-lhe gambiarra se voce quiser um comportamento bidirecional nos seus objetos.

E as interfaces? Com as gambiarras de guids? Aquilo é horrivel.

Sem contar os “problemas” de sintaxe do pascal. Pra alterar um metodo tem que alterar em dois lugares, declarar um cabecalho, depois escrever o metodo no corpo. Terrivel.

Variaveis só podem ser declaradas no inicio do metodo. Chatinho tambem.

E uma das piores pra mim é ter que ficar escrevendo begin e end toda hora, faca a conta e vai ver no fim do dia o tempo que voce perdeu fazendo isso.

Alem da ja citada falta de suporte e interesse das empresas por tras dele de facilitar programacao OO. Esse tal foco na produtividade é um tiro no pé, porque a forma de desenvolvimento normalmente adotada traz ilusao de produtividade, voce clica no botao e sai e escrevendo. Isso só é produtivo se voce for fazer uma agenda telefonica, qualquer coisa mais complexa esbarra na enorme quantidade de codigo duplicado, de regras implementadas de formas obscuras e sujeitas a erros, que ja comecam a atrasar um projeto muito antes de ser implantado.

Sim, é possivel fazer sistemas de grande porte com Delphi, como ja vi varios. Acredito que tambem seja possivel faze-los com qualidade, embora nunca tenha visto nenhum. Mas por que eu vou sofrer tentando contornar os problemas da linguagem se eu tenho outras que me dao muito mais ferramentas, e mais simples, pra atingir o mesmo objetivo?

A unica coisa que eu gosto no Delphi é a facilidade de se criar layout de telas para desktop, coisa que até hoje nenhuma ferramenta do Java chegou perto de fazer. Mas mesmo assim quando preciso fazer algo para desktop uso C#, que tem a mesma facilidade pra criacao de layouts que o Delphi e praticamente a mesma facilidade para suporte OO do Java.

Finalmente uma mente pensante nesta discussão.

YvGa:

Eu trabalhei muito tempo com Delphi e nao tenho medo de dizer que ele é terrivel. É OO? pode até ser, mas…

E a erro de referencia circular? Se a classe A referencia a classe B, entao a classe B nao pode referenciar a classe A, e dá-lhe gambiarra se voce quiser um comportamento bidirecional nos seus objetos.

E as interfaces? Com as gambiarras de guids? Aquilo é horrivel.

Sem contar os “problemas” de sintaxe do pascal. Pra alterar um metodo tem que alterar em dois lugares, declarar um cabecalho, depois escrever o metodo no corpo. Terrivel.

Variaveis só podem ser declaradas no inicio do metodo. Chatinho tambem.

E uma das piores pra mim é ter que ficar escrevendo begin e end toda hora, faca a conta e vai ver no fim do dia o tempo que voce perdeu fazendo isso.

Alem da ja citada falta de suporte e interesse das empresas por tras dele de facilitar programacao OO. Esse tal foco na produtividade é um tiro no pé, porque a forma de desenvolvimento normalmente adotada traz ilusao de produtividade, voce clica no botao e sai e escrevendo. Isso só é produtivo se voce for fazer uma agenda telefonica, qualquer coisa mais complexa esbarra na enorme quantidade de codigo duplicado, de regras implementadas de formas obscuras e sujeitas a erros, que ja comecam a atrasar um projeto muito antes de ser implantado.

Sim, é possivel fazer sistemas de grande porte com Delphi, como ja vi varios. Acredito que tambem seja possivel faze-los com qualidade, embora nunca tenha visto nenhum. Mas por que eu vou sofrer tentando contornar os problemas da linguagem se eu tenho outras que me dao muito mais ferramentas, e mais simples, pra atingir o mesmo objetivo?

A unica coisa que eu gosto no Delphi é a facilidade de se criar layout de telas para desktop, coisa que até hoje nenhuma ferramenta do Java chegou perto de fazer. Mas mesmo assim quando preciso fazer algo para desktop uso C#, que tem a mesma facilidade pra criacao de layouts que o Delphi e praticamente a mesma facilidade para suporte OO do Java.

A sintaxe do O Pascal é muito boa. Quanto a isso não tenho do que me queixar. Mas é questão de gosto. Sintaxes a lá c (Java C#) são mais dinâmicas, mas pode acreditar que o código suja com muito mais facilidade.

Também penso assim. Além do mais, testar igualdade com o sinal = é muito mais intuitivo do que com ==. E atribuição, := é muito mais intuitivo pra quem lê do que um =.
Mas é questão de gosto. Um código bem escrito em Delphi é muito legível e produtivo, tanto pra desenvolver quanto pra dar manutenção. Já vi vários códigos de grande porte e bem escritos. MVC? O Delphi fazia isso com desenvolvimento três camadas muito antes de entrar na moda. Design Patterns? Quem instalasse as versões enterprise conseguia organizar e ver ele na prática.

O que acontece com o Delphi, é que foi uma das linguagens pioneiras na orientação objeto que pegou volume de mercado. Ele “herdou” os programadores de linguagens procedurais que não tinham noção nenhuma da orientação a objeto. Forçar essa massa gigante de desenvolvedores a mudar o paradigma não é fácil, por isso a maioria deles conseguiu ir pro Delphi mas levando alguns vícios junto.

A vantagem do Delphi foi conseguir um caminho intermediário e direcionar o pessoal a um novo paradigma de programação. Pra uma empresa pequena como a Borland e que vivia em problemas financeiros, foi um ganho e tanto. Infelizmente eles não conseguiram dar o passo seguinte: trabalhar com o código 100% OO sem grandes mudanças no seu software.

Outra coisa, quem usa o Hibernate hoje, carregando as classes POJO, ficou muito parecido com a forma do Delphi trabalhar os componentes TQuery e TTable. Sinal que o Java está conseguindo unir os dois mundos também.

marcosalex:

juliocbq:

A sintaxe do O Pascal é muito boa. Quanto a isso não tenho do que me queixar. Mas é questão de gosto. Sintaxes a lá c (Java C#) são mais dinâmicas, mas pode acreditar que o código suja com muito mais facilidade.

Também penso assim. Além do mais, testar igualdade com o sinal = é muito mais intuitivo do que com ==. E atribuição, := é muito mais intuitivo pra quem lê do que um =.
Mas é questão de gosto. Um código bem escrito em Delphi é muito legível e produtivo, tanto pra desenvolver quanto pra dar manutenção. Já vi vários códigos de grande porte e bem escritos. MVC? O Delphi fazia isso com desenvolvimento três camadas muito antes de entrar na moda. Design Patterns? Quem instalasse as versões enterprise conseguia organizar e ver ele na prática.

O que acontece com o Delphi, é que foi uma das linguagens pioneiras na orientação objeto que pegou volume de mercado. Ele “herdou” os programadores de linguagens procedurais que não tinham noção nenhuma da orientação a objeto. Forçar essa massa gigante de desenvolvedores a mudar o paradigma não é fácil, por isso a maioria deles conseguiu ir pro Delphi mas levando alguns vícios junto.

A vantagem do Delphi foi conseguir um caminho intermediário e direcionar o pessoal a um novo paradigma de programação. Pra uma empresa pequena como a Borland e que vivia em problemas financeiros, foi um ganho e tanto. Infelizmente eles não conseguiram dar o passo seguinte: trabalhar com o código 100% OO sem grandes mudanças no seu software.

Outra coisa, quem usa o Hibernate hoje, carregando as classes POJO, ficou muito parecido com a forma do Delphi trabalhar os componentes TQuery e TTable. Sinal que o Java está conseguindo unir os dois mundos também.

Sem falar que tudo isso que vimos no c# seria do OPascal, se a borland não tivesse feito a besteira de não investir no Anders.
para falar a verdade, o delphi era o carro forte da borland, não sei o que aconteceu para ela mudar o foco do investimento no ponto net.

Até concordo, mas é bem mais chato escrever := do que =.

Um código bem escrito é legivel e produtivo em qualquer linguagem, mas em Delphi é mais dificil escrevê-lo por causa de algumas limitacoes. Sendo a principal delas a terrivel referencia circular. Alem da quase nulidade de ferramentas que apoiassem o desenvolvimento OO. O Delphi sempre foi voltado para tratar tudo como cruds simples, e nao da pra por a culpa so nos desenvolvedores nao. Toda a documentacao e toda a literatura do Delphi é organizada dessa forma.

Tres camadas em Delphi? Na verdade normalmente sao duas, interface com o usuario e banco, sendo que as regras ficam ou no botao ou no banco. Pelo menos foi o que eu sempre vi.

Na verdade quem direcionou o pessoal rumo a OO foi o Java e nao o Delphi, o que a Borland fez foi adaptar o pascal a OO pra abracar o paradigma que ja crescia, mas a popularizacao mesmo veio com o Java.

Nao consigo ver essa relacao, a TQuery e a TTable sao a representacao fiel da tabela do banco na memoria, o que vai completamente na direcao oposta da proposta do Hibernate.

YvGa:

marcosalex:

Também penso assim. Além do mais, testar igualdade com o sinal = é muito mais intuitivo do que com ==. E atribuição, := é muito mais intuitivo pra quem lê do que um =.

Até concordo, mas é bem mais chato escrever := do que =.

Um código bem escrito é legivel e produtivo em qualquer linguagem, mas em Delphi é mais dificil escrevê-lo por causa de algumas limitacoes. Sendo a principal delas a terrivel referencia circular. Alem da quase nulidade de ferramentas que apoiassem o desenvolvimento OO. O Delphi sempre foi voltado para tratar tudo como cruds simples, e nao da pra por a culpa so nos desenvolvedores nao. Toda a documentacao e toda a literatura do Delphi é organizada dessa forma.

Tres camadas em Delphi? Na verdade normalmente sao duas, interface com o usuario e banco, sendo que as regras ficam ou no botao ou no banco. Pelo menos foi o que eu sempre vi.

Na verdade quem direcionou o pessoal rumo a OO foi o Java e nao o Delphi, o que a Borland fez foi adaptar o pascal a OO pra abracar o paradigma que ja crescia, mas a popularizacao mesmo veio com o Java.

Nao consigo ver essa relacao, a TQuery e a TTable sao a representacao fiel da tabela do banco na memoria, o que vai completamente na direcao oposta da proposta do Hibernate.

O O Pascal já existe ha muito tempo, antes da borland.
O código pascal é mais legível justamente porque a linguagem é bem mais regrada e tipada.

um laço em pascal é simples:

for i:=0 to x do

enquanto variantes do c++ precisam

for(int i=0;i<x;i++)

o quesito abaixo, te impede de declarar varáveis ao meio do código dificultando a compreensão

var x:Integer; begin end;

Nunca usei regras diretamente no botão, nem no banco. O delphi na época(E olha que tem tempo), sempre teve uma classe para exercer encapsulamento delas.

Sobre o :=, imagine comparar igualdade com ==, sendo que em pascal basta somente = (Mas é questão de gosto).

Eu imagino que a culpa de softwares mal feitos sejam dos programadores, e não de linguagens ou ferramentas de desenvolvimento.

É evidente que a culpa nao eh da linguagem, mas as empresas que dao suporte a linguagem nunca se preocuparam e dar alternativas aos desenvolvedores. Ou faz como eles querem ou sai fora.

Talvez voce nao tenha escrito regra no botao, mas tambem nao deve te-las escritos em objetos representando seu dominio, com suas responsabilidades bem definidas, com um mecanismo de persistencia transparente pra eles. Voce tinha que escrever e reescrever e alterar N classes cada vez que alterasse a regra e perder muito tempo escrevendo codigo repetitivo se quisesse de fato usar um modelo de dominio com Delphi.

Ou voce se adaptava a linguagem e fazia como a Borland queria que fosse feito.

YvGa:

É evidente que a culpa nao eh da linguagem, mas as empresas que dao suporte a linguagem nunca se preocuparam e dar alternativas aos desenvolvedores. Ou faz como eles querem ou sai fora.

Talvez voce nao tenha escrito regra no botao, mas tambem nao deve te-las escritos em objetos representando seu dominio, com suas responsabilidades bem definidas, com um mecanismo de persistencia transparente pra eles. Voce tinha que escrever e reescrever e alterar N classes cada vez que alterasse a regra e perder muito tempo escrevendo codigo repetitivo se quisesse de fato usar um modelo de dominio com Delphi.

Ou voce se adaptava a linguagem e fazia como a Borland queria que fosse feito.

Mas a culpa disso não é da linguagem O Pascal. Java sem hibernate cai nas mesmas questões citadas ae. Na época não existia hibernate nem castle. Se alguém abraçar a causa pode escrever um modelo de persistência para a vcl, e vai ser tão boa e produtiva quando hibernate.

Se você disser que os framework java são melhores que os do delphi eu concordo, mas em questões de linguagem, de jeito nenhum. Ainda hoje pascal é sinonimo de tecnologia no MIT.

Eu, hein… É cada uma que aparece… Se quiser ver o Delphi voando baixo, usando muita OO, aproveitamento de código entre outras coisas, dá um pulinho aqui na Santri.
É lógico que existem diferenças, como a questão da Interface que o próprio Chun citou em uns tópicos atrás, mas isso não impede de fazer uma coisa bem feita e com produtividade.
Sempre que vejo um programador Java ou C# detonar o Delphi, com meia dúzia de perguntas percebo logo que o cara não saca muito da linguagem.
A gente tem que botar na cabeça que somos programadores, e não programadores Delphi ou programadores Java.

Inté.

marciosantri:

Eu, hein… É cada uma que aparece… Se quiser ver o Delphi voando baixo, usando muita OO, aproveitamento de código entre outras coisas, dá um pulinho aqui na Santri.
É lógico que existem diferenças, como a questão da Interface que o próprio Chun citou em uns tópicos atrás, mas isso não impede de fazer uma coisa bem feita e com produtividade.
Sempre que vejo um programador Java ou C# detonar o Delphi, com meia dúzia de perguntas percebo logo que o cara não saca muito da linguagem.
A gente tem que botar na cabeça que somos programadores, e não programadores Delphi ou programadores Java.

Inté.

Nao estou dizendo que nao eh possivel, estou dizendo que as empresas por tras do Delphi nunca facilitaram isso.

Julio, ja houve tentativas de se fazer um framework de persistencia em Delphi, TODAS elas abandonadas, inclusive a da propria Borland com o Bold que nao deu em nada. Eu mesmo fiz uma no padrao Active Record, usando, evidentemente o TQuery e TClientDataSet, mas tudo fica mais ou menos.

YvGa:

marciosantri:

Eu, hein… É cada uma que aparece… Se quiser ver o Delphi voando baixo, usando muita OO, aproveitamento de código entre outras coisas, dá um pulinho aqui na Santri.
É lógico que existem diferenças, como a questão da Interface que o próprio Chun citou em uns tópicos atrás, mas isso não impede de fazer uma coisa bem feita e com produtividade.
Sempre que vejo um programador Java ou C# detonar o Delphi, com meia dúzia de perguntas percebo logo que o cara não saca muito da linguagem.
A gente tem que botar na cabeça que somos programadores, e não programadores Delphi ou programadores Java.

Inté.

Nao estou dizendo que nao eh possivel, estou dizendo que as empresas por tras do Delphi nunca facilitaram isso.

Julio, ja houve tentativas de se fazer um framework de persistencia em Delphi, TODAS elas abandonadas, inclusive a da propria Borland com o Bold que nao deu em nada. Eu mesmo fiz uma no padrao Active Record, usando, evidentemente o TQuery e TClientDataSet, mas tudo fica mais ou menos.

Abandonadas pela borland sim, assim como o delphi mesmo. Não deram em nada por problemas de má adiministração, e acabaram também perdendo um grande engenheiro que foi para a microsoft.

O lazarus é hoje melhor que o delphi foi, além de possuir um compilador fiel ao object pascal e com suporte a instruções mmx. Com certeza um projeto opensource de persistência daria muito certo.

Errado, se você olhasse os tópicos de Delphi no seu auge, veria que a maioria já desenvolvia em três camadas em Delphi, seja com COM, Corba, Socket ou SOAP. Ele consegue trabalhar de forma transparente da tecnologia.

Não, o Java já pegou um público com conceitos intermediários.

YvGa:

Nao consigo ver essa relacao, a TQuery e a TTable sao a representacao fiel da tabela do banco na memoria, o que vai completamente na direcao oposta da proposta do Hibernate.

juliocbq:

Abandonadas pela borland sim, assim como o delphi mesmo. Não deram em nada por problemas de má adiministração, e acabaram também perdendo um grande engenheiro que foi para a microsoft.

O lazarus é hoje melhor que o delphi foi, além de possuir um compilador fiel ao object pascal e com suporte a instruções mmx. Com certeza um projeto opensource de persistência daria muito certo.

Essa história de jogar o mérito no Anders é meio lenda. Borland e MS sempre teve técnico saindo de uma empresa e trabalhando em outra. Aliás, entre a maioria das empresas de tecnologia. O cara não era nem o engenheiro principal do Delphi, era um dos bons, mas não era o único.

Sou mais a má administração e os problemas financeiros típicos de uma empresa pequena e instável.
Faz muito tempo que mexi com o Lazarus (acho que a versão era 0.9.26), e ele era próximo ao Delphi 3, gerava código muito grande, não tinha um debug decente e ninguém conseguia programar 3 camadas com ele direito.

Já vi coisas incríveis sendo feitas em Delphi e, sabem de uma coisa? Pode-se dizer que Delphi possui um único problema, que já não existe mais: a Borland.

marcosalex:

juliocbq:

Abandonadas pela borland sim, assim como o delphi mesmo. Não deram em nada por problemas de má adiministração, e acabaram também perdendo um grande engenheiro que foi para a microsoft.

O lazarus é hoje melhor que o delphi foi, além de possuir um compilador fiel ao object pascal e com suporte a instruções mmx. Com certeza um projeto opensource de persistência daria muito certo.

Essa história de jogar o mérito no Anders é meio lenda. Borland e MS sempre teve técnico saindo de uma empresa e trabalhando em outra. Aliás, entre a maioria das empresas de tecnologia. O cara não era nem o engenheiro principal do Delphi, era um dos bons, mas não era o único.

Sou mais a má administração e os problemas financeiros típicos de uma empresa pequena e instável.
Faz muito tempo que mexi com o Lazarus (acho que a versão era 0.9.26), e ele era próximo ao Delphi 3, gerava código muito grande, não tinha um debug decente e ninguém conseguia programar 3 camadas com ele direito.

Não acho. O anders quem criou a linguagem delphi, que é uma adaptação do opascal, e consequentemente criou o c# para a ms, com cahe de $1000000. Quando ele saiu para a ms, a borland quebrou em menos de 6 meses.

Sobre o lazarus, o freepascal é muito superior ao delphi, e o código só é grande se você não estripar as informações de depuração do código, que com ela dá uns 12 megas. Sobre o debugger, eu concordo com você, o do delphi era melhor, mas lazarus tem atualizações diárias.

A lcl também é bem melhor que a vcl, além de ser totalmente compatível e multiplataforma.

Uma empresa não quebra em 6 meses por causa de um funcionário. Ele pode ter ajudado, mas a situação da empresa era endêmica. O JBuilder vendia mais que o Delphi nos Estados Unidos, mas ele também decaiu junto por uma série de motivos que nós sabemos (e não tinha nada a ver com o Anders).

Não acho o Lazarus superior ao Delphi, uma vez que a lcl não tem nem 20% das funções da VCL, embora tenha algumas coisas legais. Mas é questão de opinião.

marcosalex:

juliocbq:

Não acho. O anders quem criou a linguagem delphi, que é uma adaptação do opascal, e consequentemente criou o c# para a ms, com cahe de $1000000. Quando ele saiu para a ms, a borland quebrou em menos de 6 meses.

Sobre o lazarus, o freepascal é muito superior ao delphi, e o código só é grande se você não estripar as informações de depuração do código, que com ela dá uns 12 megas. Sobre o debugger, eu concordo com você, o do delphi era melhor, mas lazarus tem atualizações diárias.

A lcl também é bem melhor que a vcl, além de ser totalmente compatível e multiplataforma.

Uma empresa não quebra em 6 meses por causa de um funcionário. Ele pode ter ajudado, mas a situação da empresa era endêmica. O JBuilder vendia mais que o Delphi nos Estados Unidos, mas ele também decaiu junto por uma série de motivos que nós sabemos (e não tinha nada a ver com o Anders).

Não acho o Lazarus superior ao Delphi, uma vez que a lcl não tem nem 20% das funções da VCL, embora tenha algumas coisas legais. Mas é questão de opinião.

Eu levo em conta a lcl ser multiplataforma. Ela pode não ter a quantidade de componentes, mas eles fazem o que propõem. Além do free pascal compilar para micros arm. Existe uma versão do lazarus que usa o framework qt. Da ultima vez que usei não estava estável, e preferi ficar com o padrão.

marcosalex:

Errado, se você olhasse os tópicos de Delphi no seu auge, veria que a maioria já desenvolvia em três camadas em Delphi, seja com COM, Corba, Socket ou SOAP. Ele consegue trabalhar de forma transparente da tecnologia.

Se pegou nao foi por heranca do Delphi, cite algo na literatura sobre Delphi que indicasse que o publico ja tinha esses conceitos. Nao ha nada, mesmo entre os mais famosos autores, os topicos sobre OO nao passam de algumas paginas. De resto é só estudo da vcl.

marcosalex:

Não, não são. Se você olhar a declaração de um TQuery ou TClientDataSet vai ver que nada mais é que uma classe com os atributos e que as operações que você trabalha nelas são armazenadas no banco de dados. Inclusive você pode ter um campo que seja um outro TDataSet, assim como o Hibernate faz com as chaves estrangeiras.
A diferença é que as operações do banco no Java geralmente utilizamos outra classe pra fazer isso, como as DAO, enquanto no Delphi é a própria classe que representa a tabela que faz a operação direta. A não ser que você use Bold ou BDP, que implementam o padrão DAO.

Provavelmente sim, o maior problema do Delphi sempre foi a Borland, mas eu confesso que nao sinto a menor falta dele. Com C# eu tenho tudo que tinha em Delphi, com uma linguagem (na minha opiniao) mais agradavel e com bom suporte a desenvolvimento de um modelo de dominio rico.