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

[Samu]

Queria por meio deste parabenizar o colega Stanis pelo post IRADO....

Por levantar uma questão mto interessante, e realmente mtos programadores TRABALÃO com delphi, vb e só porque compilão com uma ferramenta q da o suporte a OOP achão q realmente estão criando uma aplicação orientada a objeto...
:xau

[Maligno]

Uma correção: os que programam em Delphi e não usam os recursos da OOP diretamente, ainda assim têm uma aplicação totalmente orientada a objetos, já que a VCL (framework do Delphi) é totalmente OOP. O programador pode optar por não criar classe alguma, mas ele vai usar os componentes OOP que a ferramenta oferece. Nem que seja apenas para programar eventos.

[Samu]

Ok Realmente tens razão maligono... Me exprecei mal desculpa...

Da procima irem pensar 2X antes de postar qualquer coisa... vlw.
obrigado pela correção... sou novato ainda hehehe

[Maligno]

Não precisa se desculpar. Mas nota-se nobreza em você por admitir que errou. Confusões acontecem com qualquer um, seja por que motivo for. Por mais que me esforce, comigo também acontece. Por isso alguém sempre aparece com uma correção e alguma informação a mais. E aprendemos um pouco mais. Pois é esse o objetivo do fórum.

[edmarfrazao]

esta discussão foi proveitosa para todos.

Mas vamos continuar aos exemplos ..

[Maligno]

Mas você próprio pode continuar, Edmar. Fique à vontade.

[Stanis Luksys]

Assim que sobrar um tempo, o que está muito difícil de acontecer, eu volto a dar algum exemplo. Até tenho algo pronto, mas já embutido no sistema e sem valor como exemplo.

Pra quem quer entrar na onda da OOP, sugiro fazer alguns testes com a HWGUI, assim já se acostuma ao menos com a sintaxe usada no xHarbour para se trabalhar com classes e objetos. Neste caso as classes já estarão prontas, mas podem ser alteradas.

No entanto o meu foco aqui quando postei, foi de passar para o xHarbour, dentro de suas limitações, algumas coisas que aprendi na aula de Java e Engenharia de Software na faculdade - trabalhar os dados sempre através de classes.

De qualquer forma, quem quiser aprender é só abrir alguns fontes do contribute, a maioria das libs é OOP.

Falou!

[edmarfrazao]

Não aprendi a trabalha com OOP, comecei em 1997 com cobol(não tinha computador), conheci o dbase em 2000, passei para o clipper 5 e estou até hoje com o clipper 5.2.
Em 2001 consegui comprar um computador e inicie o desenvolvimento profissional. Passei por delphi. Comecei em 2005 com xharbour. Hoje já converti todos os meus sistemas para xharbour com wvw e agora estou implementando hwgui.


Durante os anos aprendi por conta própria a desenvolver e implementei varias funções reutilizáveis no meu sistema.

Estas implementações me propiciaram a conversão para xharbour e hwgui com pouco trabalho.

Um exemplo

No sistema tinha uma função: Confirma, em todo sistema usava a mesma função.
Para passar para hwgui , bastei converter a função para hwgui e todo o sistema onde se utilizava esta função passou para o modo gráfico.

Tenho funções genéricas para:
Menu
Cadastro
Abertura de Arquivos
Relatórios

Um exemplo de relatórios:
Há vantagem e que para todo relatório basta criar a função dados e chamar a função realtorio.
Na função relatório fica toda a lógica, então para passar para hwgui, bastei reescrever a função relatório e todos os relatórios do meu sistema passara para aproveitar os recursos da hwgui.

Procedure relbanco()
IF !AbreArquivo(,,,,[BANCOS]) ; RETURN NIL ; ENDIF
DBGOTOP()
PRIVATE FILTRO:=[],V_EVE_ANT:=[],SOMA_VR:=0,SOMA_QTD:=0;
,SOMA_DES:=0,SOMA_PRO:=0
TITULO='Emiss„o de Cadastro de Bancos'
TEXTO1=[CODIGO DESCRI€ŽO AGˆNCIA]
*CABECA_PRN := {|| FO_R1_CAB()}
*RODAPE_PRN := {|| FO_R1_ROD()}
DADOS_PRN := {|| FO_R1_DAD()}
RELATORIO(1,,TITULO,TEXTO1)
Lib_Areas()
RETURN .T.

FUNCTION FO_R1_DAD()
@ PROW()+1,4 SAY CODIGO_BAN
@ PROW(),24 SAY PADC(IMPAC(DESC_BAN),25)
@ PROW(),64 SAY AGEN_BAN
RETURN .T.




////////////////////////////
Funções genéricas:

AbreArquivo // tendo uma função que abre os arquivo evita-se de esquecer de abrir determinado índice, e se precisar acrecentar novo índice, base incluir em uma opção que estará disponível em todo o sistema

FUNCTION AbreArquiv(A,B,C,D,Arquivo)
// para reduzir omiti algumas opções referente aos parâmetros, a intenção era informar
//a->abrir na mesma area
//b->abertura exclusiva
//c->abertura somente leitura
//D->bloquerar ultimo registro
/
LOCAL ABERTURA:=.F.
PRIVATE ARQ:=[],MATIND[10]
IF LEN(ARQUIVO)=0 ; MOSTRA_MSG([Arquivo nao especificado])
ELSEIF Arquivo$[BANCOS]
USE SIBANCO INDEX SIBAN001,SIBAN002 NEW SHARED

ELSEIF Arquivo$[] ;
ELSE ; MOSTRA_MSG([Arquivo nao especificado])
ENDIF

///
Função relatório()
... implementação
... seleciona a impressora ou vídeo ou modo grafico(impressao window)
.. faz um do while do inicio a fim do arquivo corrente e cada registro chama a função dados_prn()
..checa se esta no final do papel e passa para a próxima folha
Finaliza o relatório

[Stanis Luksys]

Opa,

É legal sua história, fico feliz que tenha aproveitado os recursos da linguagem da melhor maneira, e vejo que isso facilitou o processo de migração, como há muito tempo temos exposto.

No entanto, nada tem a ver com OOP estes seus exemplos, e sem querer desanima-lo, são os mais comuns possíveis.

Espero que continue com essa vontade de se aprimorar, quem sabe começando a fazer uso de uma programação mais estruturada, com OOP. No xHarbour mesmo para começar está de ótimo tamanho.

Outra coisa, o simples exemplo postado no ínicio do tópico, creio eu ser suficiente para que se inicie algum estudo.

Valeu!!

[edmarfrazao]

Os exemplo são comuns para bons programadores.

Tenho 04 programadore aqui na minha empresa, que desenvolvem em delphi e praticamente não criam funções que podem ser reutilizadas no resto do sistema.

Muinto programadores somente procuram resolver o problema no momento. Não se preocupam de criar codigos reutilizaveis.


com relação a OOP , disse que o codigo não era , mas se tivesse aprendido OOP teria criado a função relatorio como uma.

E mesmo ela não sendo OOP , mostra uma maneira interessante de reutilização de codigo

[Stanis Luksys]

Tenho 04 programadore aqui na minha empresa, que desenvolvem em delphi e praticamente não criam funções que podem ser reutilizadas no resto do sistema.

Realmente acontece bastante nas linguagens que possuem poderosas IDEs. Isso porque o ambiente de trabalho é bem simplificado, intuitivo. É simples criar telas e adiconar eventos a objetos.

Deste modo muitos programadores acabam não conhecendo mais a fundo a ferramenta que possuem, não conhecem nem sequer a velha estrutura do pascal (eu ainda lembro do PROGRAM na primeira linha) para poder aplicar conhecimento em Delphi. Sendo assim, pelas facilidades, muitos acabam ficando preso ao ambiente, não entendendo como se declarar uma nova função sem que isto seja feito automaticamente pela ferramenta.

Mas mesmo assim, é questão de tempo, um dia todos nós aprendemos a reutilizar código, fazer uma programação mais modular.

É questão de experiência.

[vagucs]

So dizendo novamente.

OOP deixa o codigo mais legivel, organizado e até "bonito", mas não acarreta ganho de performance, pelo contrario, pode acarretar até uso de excesivo de memoria quando comparado a sintaxe tradicional não OOP, onde cada membro seria uma variavel. OOP tem ganho na organização e até de memoria, quando todos os membros de uma classe são usados, o que quase não acontece no caso de classes já prontas.

Mesmo assim, OOP é muito bom e um padrão já bem aceito.

[Maligno]

OOP é uma ferramenta complexa que foi inventada em decorrência da necessidade de se resolver problemas complexos com mais eficiência. Também como resultado disso, OOP não torna o código mais legível ou mais "bonito". Acho que qualquer código, baseado no paradigma que for, se bem escrito, tornará o código mais facilmente reutilizável, legível e fácil de manter. Além do que, OOP não dispensa o código estruturado.

[Stanis Luksys]

Olá,

Independente da dificuldade de se codificar o programa, da beleza e da estrutura, OOP é o mais indicado para aplicativos que trabalham com bancos de dados.

Hoje praticamente é apenas desta forma que se ensinam nas escolas e se publicam em livros, no que se refere a análise de sistemas de informação e engenharia de software. Claro que nem sempre é assim quando se trata do estudo dos recursos de uma linguagem específica.

A intenção da OOP não é, definitivamente, ganhar desempenho. É facilitar processos de análise e prinicpalmente documentação e planejamento de software.

Enfim, no xHarbour eu não sei, até pelas suas limitações, mas na teoria em geral, é o caminho mais "certo" a ser seguido.

Falou!

[Maligno]

na teoria em geral, é o caminho mais "certo" a ser seguido.

Acho que essa afirmação é forte demais. Diria que OOP é um caminho que pode ou não ser o ideal. Vai da aplicação. E além disso, o programador tem de saber usar muito bem. OOP também é ótimo para produzir gargalos no programa.