xHarbour 100% Orientado a Objetos - Uma pequena introdução

[gransoft]

UBERLÂNDIA-MG, 14 de maio de 2007.

Prezados Srs.,

Também acompanho!

E logo alguém postará aqui algo sobre Desenvolvimento e Execução em Três Camadas, Servidor de Objetos, Banco de Dados e Aplicativos...

Atenciosamente,
Janis Peters Grants.

[momente]

Amigos,

Muito bom este tópico!

O Maligno Citou:

Ele apenas e tão somente lê o código XBase e cria uma série de chamadas de funções que fazem um "empilhamento" de comandos, símbolos, etc. Ao final, é executada a função hb_vmExecute, que faz a VM a executar o procedimento empilhado.

Gostaria de saber oque realmente desabona o xharbour frente as outras linguagens por tratar o código assim usando uma VM?

Valeu mestres!

[Maligno]

Gostaria de saber oque realmente desabona o xharbour frente as outras linguagens por tratar o código assim usando uma VM?

Não é o caso de desabonar o XHarbour. Acontece que, por questões de facilidades técnicas, desde o princípio do desenvolvimento do Harbour, optou-se pelo uso de uma máquina virtual. Ela trabalha com opCodes, assim como a VM do Clipper. Para facilitar o trabalho, optaram pelo uso de um analisador léxico (não lembro o nome - acho que é Simplex). Isso facilita o trabalho de compilação, pois ele traduz os comandos XBase para os opCodes, gerando arquivos fonte em C que fazem o trabalho de empilhamento, para depois invocar a VM para execução.
Trabalhar assim facilitou enormemente o projeto. Se fosse pra gerar código binário o trabalho realmente aumentaria muito. O uso de uma VM realmente torna o compilador mais facilmente portável para outras plataformas operacionais. Se usassem código C ANSI, isso também seria possível, só que a um custo maior.

Como tudo na vida tem um preço, o uso de uma VM impõe um overhead maior ao processador. Se fosse código binário puro, logicamente a velocidade seria bem maior. Felizmente, a VM ainda assim tem uma velocidade muito boa. Mas isso explica o porquê de um código binário do Delphi, por exemplo, ser mais rápido que um código (tecnicamente equivalente) executado pela VM do XHarbour.

[]'s
Maligno
http://www.buzinello.com/prg

[momente]

Amigo Maligno,

Muito obrigado por esta explicação!

Valeu!

[Stanis Luksys]

E logo alguém postará aqui algo sobre Desenvolvimento e Execução em Três Camadas, Servidor de Objetos, Banco de Dados e Aplicativos...

Fique a vontade, está aberto o convite... hehehehe

Agora falando sério, no primeiro tópico quando eu disse de converter código xbase em código C foi realmente uma maneira infeliz de apenas dizer que seu binário final será gerado pelo compilador C, seja qual for. Eu não quis dizer ao pé da letra que ele pega e "traduz" say para printf. De qualquer forma foi muito útil a explicação que o Maligno e o Wagner deram de como funciona este processo.

Eu comecei este tópico porque eu trabalho já algum tempo com migração e mesmo manutenção simples em sistemas Clipper, ja vi (pelo menos trechos) de dezenas de sistemas, e a coisa mais perto que vi de OOP foi o uso de matrizes combinadas com translates para gerar a sintaxe "cliente.nome" ou "produto.codigo".

No caso de Delphi e VB, mesmo juntando as duas eu não vi nem metade da quantidade de sistemas que vi no Clipper, mas em tudo que ví até hoje só uma vez me deparei com um sistema feito todinho orientado a objetos, em Delphi, em VB eu nem nunca vi. Mas como eu disse eu não vi tantos assim, mas é razoavelmente difícil de se encontrar.

[Pablo César]

Sim, de fato é impressionante o nível de conhecimento que os colegas tem apresentado. Pelo que posso eu entender, aquí é um banco de dados de estimada informação, composta pelos nobres colegas e olha que ficaram muitos ainda sem se manifestarem neste tópico. Mas com certeza esta abordagem é importante para comprender mais um pouco a arquitetura do xHarbour. Reconheçamos que o xHarbour tem seus méritos e que permitem a todos nós darmos continuidade aos conhecimentos que já possuíamos. Claro que a linguagem C é o pai das outras subsequentes. Mas enfim, gostamos muito quando uma linguagem simplifica a nossa tão árdua tarefa de programar, porque se torna amigável e poderosa.

Obrigado Stanis por ter trazido até nós este tópico e obrigado Maligno e Wagner pelas suas contribuições, enfim obrigado a todos que ajudam a enriquecer este FORUM.

:)Pos -:] :{ :*

[vagucs]

Orientado a objeto ou não, no final tudo é ´CÓDIGO EXECUTÁVEL, mas acho que a programação orientada a objetos é mais profissional, atual e mais compreensível e organizada.

Também parabenizo ao Stanis pelo tópico, e também quero acrescentar que maior parte dos componentes do xHarbour está sendo reescrito desde a versão 0.70 para orientação a objeto, são casos como o MEMOEDIT que conta com a a classe TMEMOEDIT entre outras, tudo interno, mas estas classes dão um poder maior de programação para quem usar elas diretamente.

[Hasse]

Um Bom dia a todos.

Apesar de afastado do Fórum por algum tempo, sempre que me era possível, dava uma espiada, e acompanhando de longe o desenrolar dos debates. Porém este em particular despertou o meu vivo interesse.

Desejo cumprimentar efusivamente o colega Stanis pelo excelente material didático postado, ensinando e mostrando, com poucas pinceladas, o que é este bicho OPP.
Como programador da "velha guarda" (em Clipper comecei com o 87, e hoje com 64 anos), já li alguns textos a respeito de OPP, porém a coisa sempre descambava muito para a teoria, e o assunto permanecia extremamente nebuloso para o velho programador procedural.
Com o pequeno e genial exemplo, a idéia geral ficou bastante clara, e achei muito interessante. Até desejo fazer incursões neste novo ambiente.

Porém, preciso colocar uma dúvida que surgiu, assim que terminei a leitura de todas as colocações acima.

Como o colega Maligno escreveu acima, "Em muitos casos, OOP nem pensar.", acredito que eu tenho um destes casos. Vou tentar descrever rapidamente:

Tenho um sistema, onde semanalmente deve ser feita uma estatística (que na realidade tratamos de FATURAMENTO), onde tenho um DBF principal que deve ser percorrido registro por registro.
Os dados colhidos deste DBF principal são remetidos para funções que realizam consultas em vários outros DBF's (que chamamos de CADASTROS).

O DBF principal tem a percorrer uns 5000 registros a cada vez, e para cada registro, devem ser feitas algo ao redor de 20 a 30 consultas aos diversos CADASTROS. Isto geraria uma "abertura" e "fechamento" de arquivos de umas 125.000 vezes.

Isto não tornaria o processamento bastante mais lento, e portanto, seria este um dos casos citados pelo Maligno ?

Com relação ao DBF principal, pelo que entendi, este deve ficar "aberto" já que todos os registros devem ser percorridos um a um. Estou correto ? Todos os demais DBF's deveriam ser "abertos" e "fechados" a cada consulta (tipo exemplo do Stanis), isto para ser considerado OPP ?

Também quero colocar a minha palavra de INCENTIVO pela continuidade dos debates de OPP.
Mais uma vez, os meus cumprimentos, Stanis. Cumprimento também os demais colaboradores, cujas observações vieram engrandecer e dar brilho ao assunto.

[Stanis Luksys]

Desejo cumprimentar efusivamente o colega Stanis pelo excelente material didático postado, ensinando e mostrando, com poucas pinceladas, o que é este bicho OPP. Como programador da "velha guarda" (em Clipper comecei com o 87, e hoje com 64 anos), já li alguns textos a respeito de OPP, porém a coisa sempre descambava muito para a teoria, e o assunto permanecia extremamente nebuloso para o velho programador procedural. Com o pequeno e genial exemplo, a idéia geral ficou bastante clara, e achei muito interessante. Até desejo fazer incursões neste novo ambiente.

Pois é, foi esta a intenção, levar a coisa pro lado prático e mostrar que num é nada difícil como dizem, é questão de programar apenas, qualquer clippero consegue.

Como o colega Maligno escreveu acima, "Em muitos casos, OOP nem pensar.", acredito que eu tenho um destes casos.

No caso o Maligno acabou por citar Compiladores e até Sistemas Operacionais, o que não estava em pauta no momento.
A verdade é que hoje existe um "senso comum" (porém baseado em estudos) de que a principio sistemas comercias, em especial os de grande porte, DEVEM SEMPRE ser OOP. Se você perder por isso 5% do seu desempenho em velocidade, você ganha outras tantas vantagens que superam isso. O mal do clippero é achar que tudo é pesado, "delphi é pesado", "java é pesado"... Mas hoje vemos PCS com processadores 32 bits, hd de 40 GB e com 256M de memoria em todo lugar facilmente. Quem quer um sistema bom não pode pensar apenas em software, hardware faz parte do jogo. E é até irônico o fato do Clipper ser tão levinho e estar perdendo espaço justamente por isso, sua "leveza" provém de sua grande falta de recursos.

O DBF principal tem a percorrer uns 5000 registros a cada vez, e para cada registro, devem ser feitas algo ao redor de 20 a 30 consultas aos diversos CADASTROS. Isto geraria uma "abertura" e "fechamento" de arquivos de umas 125.000 vezes. Isto não tornaria o processamento bastante mais lento, e portanto, seria este um dos casos citados pelo Maligno ? Com relação ao DBF principal, pelo que entendi, este deve ficar "aberto" já que todos os registros devem ser percorridos um a um. Estou correto ? Todos os demais DBF's deveriam ser "abertos" e "fechados" a cada consulta (tipo exemplo do Stanis), isto para ser considerado OPP ?ao assunto.

Veja bem, meu exemplo foi o mais simples possível, mas vou te dar umas pequenas dicas para que você possa implementar.

O comando USE que abre o arquivo pode estar no método :Novo() e depois um CLOSE em outro método :Destroi(). Neste caso note que podemos instanciar diversas vezes a mesma classe em objetos diferentes, e que portanto pode ser útil ter varias vezes o mesmo arquivo aberto em áreas diferentes, evitando que o "ponteiro" se perca a cada operação em objetos distintos. Já em outros casos isso pode acarretar perde de desempenho siginificativa. É questão de analisar suas necessidades.

Você pode também criar um objeto FATURAMENTO, e nas propriedades (data) colocar informações de diversos campos de diversos DBFs. Depois bastaria criar métodos para trabalhar em cima deste objeto.

Algo assim:

Classe TFaturamento:

Código: Selecionar todos

CLASS TFaturamento
   DATA   cliente_codigo
   DATA   venda_codigo
   DATA   arquivo55_campo33
   METHOD novo()
   METHOD fatura()
   METHOD metodo2()
   METHOD destroi()
ENDCLASS

Método Novo:

Código: Selecionar todos

METHOD novo() CLASS TCliente
   use clientes new
   use vendas new
   use arquivo55 new
   ::cliente_codigo := clientes->codigo
   ::venda_codigo := vendas->codigo
   ::arquivo55_campo33 := arquivo55->campo33
RETURN Self

No exemplo acima o certo seria criar tudo como NIL ou vazio, mas é só pra exemplificar a criação de um único objeto com várias entidades do sistema.

Fiquei aqui imaginando e já pude vislumbrar uma melhora significativa no seu código atual, se isso vier a ser implementado.

Bom, por aí vai... Espero que tenha esclarecido um pouco mais.

Falou!

[Hasse]

Boa tarde Stanis.

Colocado desta forma ficou excelente.

Ficou muito claro e acredito que assim atenderia perfeitamente as minhas necessidades.

Obrigado.

[Stanis Luksys]

Complementando...

Interessante dizer que este modelo acima é muito útil para relatórios também. Muita gente gera DBF temporário para realizar operações que utilizam 5, 10 ou 15 tabelas diferentes.

Se formos pensar em nível mais prático, usar OOP em casos como este seria extremamente útil do ponto de vista da velocidade, pois substituiria incontáveis replaces por simples atribuições de dados.

Aí alguém pode dizer: mas ué, é só não usar DBF temporário e colocar tudo em variáveis. Mas existe uma diferença importante, tratando com classes você chega ao mesmo contexto do DBF temporário, tendo os seus dados AGRUPADOS em um objeto, como se fosse mesmo uma tabela.

É isso aí, a gente vai pensando, se envolvendo e vai notando como podemos ampliar mais os horizontes com OOP.

Falou!

[mario]

Ólá!
Já que citastes o corebuilder, o que acha?
Tem futuro, continuidade este projeto, ou é uma saida definitva do clipper para Java?

[Maligno]

O modêlo de negócio do Corebuilder é extremamente agressivo, caro e fora da realidade. Já li diversos comentários negativos a respeito. Mas tecnicamente não conheço. Nunca encontrei alguém que use. Imagino que sejam poucos.

[sygecom]

Ólá!
Já que citastes o corebuilder, o que acha?
Tem futuro, continuidade este projeto, ou é uma saida definitva do clipper para Java?

Tche, jah dei uma olhada no video que demostra como ele funciona !! na teoria...ele é tudo de bom...agora eles estão oferencendo um Demo veja vc mesmo...faça seus teste..o valor é salgado...só basta vc ver se vale a pena para o seu caso...no meu não vale a pena !!!

Abraços
Leonardo Machado

[Stanis Luksys]

Olá,

É um produto bom que deve amadurecer com o tempo, no entanto é fraco quando comparado a outros frameworks do mercado que estão nas mãos de empresas consolidadas.

O único diferencial é a sintaxe xBase. Na minha modesta opinião, não vale a pena adquirir.

Existem excelentes frameworks, um que já tive a oportunidade de conhecer e gostei muito foi o genexus - http://www.genexus.com/br - trabalha com diversas sintaxes inclusive o padrão 4GL que vem ganhando grando espaço entre desenvolvedores. Suporta diversos bancos de dados e compila em várias ferramentas.

Mas mesmo assim, eu talvez não optaria por algo que seguisse este padrão de gerador de códigos. Isso é questão para se resolver através de análise e estudo de casos. É necessário o mínimo de embasamento teórico para se tomar uma decisão como esta, afinal é o futuro da sua empresa em outras mãos.

É o que eu acho.