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

[Hasse]

Maligno escreveu:

OOP também é ótimo para produzir gargalos no programa.

Você poderia explicar para nós mortais em quais casos isto pode acontecer ?

[Maligno]

Vou citar um caso de um sujeito que programa em Delphi e que criou uma série de classes para persistência de dados em Firebird. Pela descrição, o sistema ficou incrivelmente prático. Ele quase não precisava escrever qualquer comando SQL. A classe fazia tudo. Mas, em determinadas operações ocoria uma lentidão miserável. Até que ele descobriu que a culpa era justamente da classe que lhe dava conforto para trabalhar. A cada comando de consulta, por exemplo, a classe montava a query com todos os campos da tabela, ao invés de apenas usar os campos necessários. Em algumas situações, claro, a massa de dados era muito grande e ainda por cima com todos os campos. Totalmente desnecessário. Ele penou até que usou um profiler e descobriu de quem era a culpa.

Esse é só um exemplo, mas há muitos outros. Um genérico: o instanciamento de uma classe dentro de uma malha. Isso é típico. Dependendo do teor da classe, é pedir pro programa virar uma lesma manca e bêbada. ))

Dependendo do caso, um erro de lógica pode se tornar extremamente sutil. Daí vem a importância de um bom profiler que possa analisar o código e expor as métricas do sistema.

[Stanis Luksys]

É verdade, acontece.

Mas isso por que se tentou criar métodos generalistas demais, que possam ser aproveitados em muitas situações, o que apesar de poupar o programador de escrever, realmente torna o sistema mais pesado. Como foi mencionado, foi um erro de lógica, poderia acontecer mesmo na programação estruturada.

Se for usada corretamente, a OOP pode trazer bons resultados, inclusive com desempenho equivalente a programação estruturada. No caso o que é inevitável é o uso maior da memória, as vezes até desnecessário. Mas isso hoje é um problema razoavelmente simples de se contorar, até porque a empresa que banca um desenvolvimento mais completo, documentado e que segue estes princípios da OOP, pode comprar alguns pentinhos de memória.

[Maligno]

Como foi mencionado, foi um erro de lógica

Certamente um erro de lógica. Mas inicial. O rapaz consertou, inserindo flags de seleção de campos. Assim, ele pôde manter suas classes. Ficar sem sem poder usá-las seria sim um erro pior.

[Edsones]

Olá a todos,

Gostaria de saber se existe a possibilidade de criar DATAS nos objetos, em tempo de execução. Ou seja, normalmente definimos as classes e seu DATAS e instaciamos o obejto depois, mas eu tenho a necessidade de criar mais alguns DATAS durante execução do aplicativo.

[Maligno]

Existem quatro elementos básicos de uma classe: o construtor, o destrutor, o método e a propriedade. Acho que por DATA você quer dizer propriedade. Se for isso, não use o termo DATA que ninguém, que use OOP, vai entender. O termo correto é propriedade.

E, como eu disse em private, e repetindo para que os demais colegas possam compartilhar da idéia, não é possível inserir propriedades num objeto, pois este é apenas um instancionamento da classe. A classe por sua vez, é como o projeto arquitetônico do objeto. A forma que terá o objeto deve ser definido por ocasião do desenho da classe. Depois não adianta querer adicionar (ou excluir) qualquer coisa do objeto. Isso, em termos de paradigma OOP, no conceito que é convencionalmente aceito como o correto, não existe.

Agora, se por DATA você se refere a um tipo de dado, aí só depende das características da linguagem. Como o XHarbour é compatível com o Clipper, certamente deve ser possível usar o tipo de dado DATE. Ou, adicionalmente, talvez algum outro tipo (que eu não conheço) que possa armazenar datas. XHarbour não é a minha praia.

[Stanis Luksys]

Hehe...

Até onde sei, não é possível criar propriedades em classes em tempo de execução, em linguagem nenhuma. Como o Maligno disse, faz parte do próprio conceito de OOP.

Agora, o que se costuma fazer, é criar uma classe filha que herda as propriedades da mãe, e nela sim adicionar novas propriedades.

[Maligno]

Agora, o que se costuma fazer, é criar uma classe filha que herda as propriedades da mãe, e nela sim adicionar novas propriedades.

Estou achando que o colega que lançou a questão trocou as bolas. Ao invés de questionar sobre a CLASSE, trocou o nome pra OBJETO. E ao invés de propriedade, trocou o nome pra data. Ai é só confusão mesmo. Mas se for isso, é fácil mesmo, criando uma nova classe através da derivação de outra, como você citou.

Mas é como eu digo: a resposta correta começa numa pergunta bem feita. Aliás, o apêgo ao jargão técnico não é frescura acadêmica. É necessidade.



PS: Talvez não tenha nada a ver, mas tenho uma histórinha.
Outro dia, encontrei um conhecido (não é meu amigo) numa empresa. O sujeito é programador VB aposentado do Banco do Brasil, com mais de 25 anos de "experiência" no ramo. Ele comentou que naquele momento estava tendo um problema com uma função "intrínseca". De cara já imaginei o "embromation". Mas eu disse que nem imaginava o que era isso. Com um indisfarçável olhar de superioridade, ele "me ensinou" que é um tipo muito especial de função que executa ela própria várias vezes e que depois da ocorrência de certo evento, começa a retornar. Fiz cara de "impressionado", agradeci a "aula" e fui embora. ))

Moral da história: não dá pra travar um diálogo civilizado com (e ninguém leva a sério) um sujeito que sequer conhece o jargão da própria profissão.

[Maligno]

Acho que não está com nada, jargão, comparações com linguagem a, b, ou c, para uma pergunta tão simples.

Nunca é cedo ou tarde pra aprender a importância do jargão técnico. E é importante. Se não fosse, e cada um tivesse a liberdade para cunhar novos termos quando quisesse, ninguém entenderia mais ninguém. Seria uma zona. É como tradução de livro: não se traduz template para gabarito ou grid para grelha, como já vi. E quanto antes se aprende, melhor. Principalmente se for auto-didata.

Note um detalhe importante: ninguém precisa se prender apenas à pergunta de um tópico. Se há oportunidade de se passar mais algum conhecimento, que às vezes nada tem a ver com a pergunta em si, tanto melhor. Conhecimento nunca se perde. Uma pessoa que aproveite alguma coisa já basta para ter valido a pena.

Se está num tópico sobre xHarbour e o mesmo está com dúvidas sobre instruções em OOP nos padrões xHarbour, os que conhecem especificamente esta linguagem que tentem compreender/orientar ou solicitar um melhor esclarecimento.

Premissa básica de qualquer fórum: o mínimo que se pode esperar de alguém que precisa de ajuda é que se faça a pergunta corretamente, num linguajar inteligível e com dados suficientes para uma análise precisa.

Inúmeras vezes vi tópicos neste fórum com perguntas aparentemente simples, em que os colegas, tentanto ajudar, ainda têm que se dar ao trabalho de tentar adinhar o que o sujeito quer saber. Então são 2, 3, 5, 10 suposições diversas, só por quê o sujeito forneceu dados incorretos e/ou incompletos.
Não. Teoricamente, não somos nós que temos que tentar adivinhar coisa alguma. A pergunta corretamente formulada é obrigação que quem precisa de ajuda. Claro que, na boa fé, tentamos ajudar ainda assim.

[Stanis Luksys]

Stanis,
Tenho observado que esta se tornando um hábito, postar mensagens, afirmando que desconhece uma alternativa técnica que auxilie determinada pergunta (totalmente irrelevante tal informação), em alguns casos, seguida de uma contestação indireta a que tenho respondido.

Eu realmente desconheço tal alternativa, tanto que comecei minha frase com "até onde sei".

De fato, minha resposta foi contrária a sua, mas isso porque o exemplo que você colocou não apresenta a criação de uma propriedade em tempo de execução, que foi o que interpretei da questão original.

No mais não é nada pessoal, nem sequer me referi à sua resposta quando escrevi a minha. Apenas pensei em contribuir, e se ele me questionasse como então criar a classe filha no xHarbour, eu diria que não sei, nunca fiz isso nele e nem sei se existe este recurso.

[Maligno]

Mesmo que não seja este o caso, que eu saiba, contestar o post de alguém é um direito de cada um. Ou agora é proibido contestar e eu não estou sabendo?

[Stanis Luksys]

Pois é,

Veja bem, se eu tenho a intenção de contestar algo que alguém escreveu, eu geralmente cito tal afirmação e coloco a minha visão sobre o assunto.

Não foi o caso, apesar de que o exemplo dado realmente não cria propriedade em classe.

Pelo que eu entendi da questão, eu diria que o ideal é criar a classe já com as propriedades necessárias, mesmo que seu uso seja facultativo em alguns casos.

[Stanis Luksys]

Como boa prática de contestação, deve-se ter no mínimo, possuir uma informação consistente que sobreponha a outra,

Eu apresentei "informação consistente" ao demonstrar que utilizando OOP, a solução para o problema do colega se dá por meio de herança de classe.

Quer aprender ?? então analise a opção informada !! Estude os fontes que apresentei.

Aprender sempre quero, por isso estou no fórum. Mas os fontes que você apresentou, um pequeno trechinho, assim como o que indicou que fosse estudado, não realizam esta tarefa que você diz conseguir, ou seja, criar propriedades ("datas") em tempo de execução.

Não tenho muita paciência para esclarecer "pontos de vista", sou muito prático e direto, quase não contribuo diretamente com o fórum, de agora em diante farei diferente, será em private/email ou msn e postarei aqui para que procurem a alterativa com o autor da pergunta.

Sinta-se a vontade.

[Stanis Luksys]

Ah sim,

Me lembrei do que você está citando, foi quando eu disse que "nunca ouvi falar" que no DBF tem flag de índice, por onde supostamente seria possível saber quais campos estão indexados, ou qual o RDD utilizado.

Foi essa a sua resposta:

Na empresa que trabalhei há alguns anos, implementei no sistema uma consistência na abertura da tabela (DBFCDX). Se no cabeçalho do DBF tem o Flag do índice e o mesmo não existe fisicamente, entou é exibido uma advertência ao usuário solicitando a indexação do mesmo.

Bom, realmente nunca ouvi mesmo, mas talvez você demontrando, eu compreenda que apesar de eu nunca ter ouvido falar, existe.

Porque afinal, entrar no forum e escrever que tem soluções impressionantes usando recursos complexos, é fácil. Difícil é mostrar.

[Stanis Luksys]

Bom, então me diga uma coisa, alías duas.

1) Como verificar a existência de flag de índice em DBF?

2) Como criar uma propriedade em uma classe em tempo real, ou seja, sem que seja em sua declaração?

Veja só, são perguntas simples, elaboradas nas suas próprias suposições.

Aqui a grande maioria tem conhecimento suficiente para entender sua resposta, sendo ela demonstrada em pequenas pinceladas de código.

Falar por falar que não dá, e isso sim é bem mais feio que falar "não sei".