Fórum É, realmente, possível usar ECO e OO no dia a dia? #293404
27/08/2005
0
Olá, senhores.
A promessa do ECO II é maravilhosa.
Dará trabalho para aprender a pensar diferente e criar objetos que sejam, realmente, objetos completos e úteis. Mas valeria a pena se tudo, realmente, funcionasse como no manual.
Não sei quanto a vocês, mas tô cansado de ´blá-blá-blá Factory´ e nada de fazer uma ficha de cliente completa. ´Blá-bla-blá Singleton´ e nada de fazer um item de estoque ser arrastado e solto dentro de uma nota fiscal. ´Blá-blá-bla Builder´ e nada de ajudar a programar boas interfaces para os usuários, incluindo as validações em tela.
Aliás, dos softwares que vi, quanto mais ´orientada a objeto´ é a sua construção, parece que pior é a interface com o usuário. Mais difícil se torna o simples ´emitir um relatório´. Ou são prolixos: na tela de cadastrar documentos você não pode modificar um endereço, na tela de vincular um funcionário, você não pode atualizar um telefone. E por ai afora vai...
Para mim, tinha que ser assim:
Defino uma classe que é ´Pessoas´, arrasto os atributos para fazer uma tela e pronto. Do lado, tem o objeto ´TiposDePessoas´, arrasto ele para a tela de Pessoas e já sai um combo-box para eu definir se é cliente, fornecedor ou alienígena. Aliás, os eventos Entrar, Sair, Clicar, etc., além da formatação básica devem ficar todos preenchidos.
Arrasto o componente de conexão para cima de um navegador e ele já sabe ir para frente, para trás, acrescentar e editar.
Tem método ´imprimir-ficha´? Arrasto pra tela e já sai um botão. Se arrasto para cima de um menu, fica sendo sub-menu, etc.
Chega! Para mim, a OO tem que fazer isso.
Se é para ficar colocando em variável e copiando para componente de tela, depois mandando pra variável e verificar se ´aderiu´ para, só então, mandar mensagem de erros e começar tudo de novo a coisa tá meio errada.
Os Frames e os Actions já estão quebrando o meu galho. Eu quero é coisa mais prática, mais fácil.
Um diamante tem seu valor pela raridade. Uma Ferrari, um Jaguar, pela exclusividade.
Software é ferramenta. FERRAMENTA!!!
Não é o objetivo. Não é um fim. É apenas um meio de se obter isso.
Ninguém, a não ser os afetados, coloca aquela estatueta da Jaguar em outro carro. Mesmo que seja muito bom, como um Astra. Não tem significado, além de custar algumas centenas de dólares, só aquele pedacinho de metal.
A Microsoft não vende software, vende agilidade.
A Borland não vende software, vende eficácia.
Ou pelo menos é isso que eu e meus clientes queremos comprar.
Software não é ARTE, mesmo quando cunhamos termos como ´state-of-art´ para descrever os muito bons.
Tanto é que estou recebendo informações sobre dezenas de grandes empresas retornando a sistemas em interface texto com o xHarbour. Todo mundo quer o que é o melhor, mas quando não se consegue ver os benefícios, escolhemos pelo preço, mesmo. O problema é que temos investido em latarias de Ferraris com chassi Lada e motor de Chevette. Estamos com um problema sério, típico de administradores: há um desequilíbio grande entre valor e preço. Os softwraes estão cada vez mais caros, enquanto entregam cada vez menos benefícios aos clientes. Para ficar claro: colar uma estatueta de prata de um felino famoso, ágil, bonito, feroz, inteligente no capô de um Astra ou Golf não faz dele um Jaguar... Por mais que tentemos ou tentem nos fazer acreditar nisso.
Talvez, eu é que não consegui enxergar o que OO tem por fazer e como fazer tudo na prática. Mas, sem falsa modéstia, eu não sou uma pessoa que demora para entender as coisas (eu passei em 7 vestibulares, 2 vezes em Medicina, em Londrina e Florianópolis, sempre fui um dos melhores em classe, formei-me em Administração, e desenvolvo softwares há anos, alguns funcionam na versão original desde de 1987, em Clipper).
Ou, tem alguém que não contou tudo, ou não temos uma ferramenta que entregue o que a OO está prometendo (o que considero muito provável).
E, finalmente... Para fazer testes mais fáceis, ter instalação fácil, interface de controle precisa, gostaria de usar o Access junto com o ECO, mas ele não consegue gerar os scripts de construção e manutenção das tabelas.
Alguém tem uma luz que eu possa seguir? A maioria dos Tutoriais, além de tratar pouco sobre banco de dados e persistência (todos falam de InterBase, DB2, Oracle) ficam discutindo sobre ASP.Net.
Meleca... Se é para usar ASP.Net vamos direto pra o VisualStudio, ora!
Ou será que o ECO e o Delphi 2005 deixaram de ser ferramenta para quem faz pequenos softwares, para atender o escritório de advocacia, a loja de auto-peças ou a farmácia?
Quem concordar comigo, ou souber fazer críticas que possam me educar, por favor, manifeste-se.
A promessa do ECO II é maravilhosa.
Dará trabalho para aprender a pensar diferente e criar objetos que sejam, realmente, objetos completos e úteis. Mas valeria a pena se tudo, realmente, funcionasse como no manual.
Não sei quanto a vocês, mas tô cansado de ´blá-blá-blá Factory´ e nada de fazer uma ficha de cliente completa. ´Blá-bla-blá Singleton´ e nada de fazer um item de estoque ser arrastado e solto dentro de uma nota fiscal. ´Blá-blá-bla Builder´ e nada de ajudar a programar boas interfaces para os usuários, incluindo as validações em tela.
Aliás, dos softwares que vi, quanto mais ´orientada a objeto´ é a sua construção, parece que pior é a interface com o usuário. Mais difícil se torna o simples ´emitir um relatório´. Ou são prolixos: na tela de cadastrar documentos você não pode modificar um endereço, na tela de vincular um funcionário, você não pode atualizar um telefone. E por ai afora vai...
Para mim, tinha que ser assim:
Defino uma classe que é ´Pessoas´, arrasto os atributos para fazer uma tela e pronto. Do lado, tem o objeto ´TiposDePessoas´, arrasto ele para a tela de Pessoas e já sai um combo-box para eu definir se é cliente, fornecedor ou alienígena. Aliás, os eventos Entrar, Sair, Clicar, etc., além da formatação básica devem ficar todos preenchidos.
Arrasto o componente de conexão para cima de um navegador e ele já sabe ir para frente, para trás, acrescentar e editar.
Tem método ´imprimir-ficha´? Arrasto pra tela e já sai um botão. Se arrasto para cima de um menu, fica sendo sub-menu, etc.
Chega! Para mim, a OO tem que fazer isso.
Se é para ficar colocando em variável e copiando para componente de tela, depois mandando pra variável e verificar se ´aderiu´ para, só então, mandar mensagem de erros e começar tudo de novo a coisa tá meio errada.
Os Frames e os Actions já estão quebrando o meu galho. Eu quero é coisa mais prática, mais fácil.
Um diamante tem seu valor pela raridade. Uma Ferrari, um Jaguar, pela exclusividade.
Software é ferramenta. FERRAMENTA!!!
Não é o objetivo. Não é um fim. É apenas um meio de se obter isso.
Ninguém, a não ser os afetados, coloca aquela estatueta da Jaguar em outro carro. Mesmo que seja muito bom, como um Astra. Não tem significado, além de custar algumas centenas de dólares, só aquele pedacinho de metal.
A Microsoft não vende software, vende agilidade.
A Borland não vende software, vende eficácia.
Ou pelo menos é isso que eu e meus clientes queremos comprar.
Software não é ARTE, mesmo quando cunhamos termos como ´state-of-art´ para descrever os muito bons.
Tanto é que estou recebendo informações sobre dezenas de grandes empresas retornando a sistemas em interface texto com o xHarbour. Todo mundo quer o que é o melhor, mas quando não se consegue ver os benefícios, escolhemos pelo preço, mesmo. O problema é que temos investido em latarias de Ferraris com chassi Lada e motor de Chevette. Estamos com um problema sério, típico de administradores: há um desequilíbio grande entre valor e preço. Os softwraes estão cada vez mais caros, enquanto entregam cada vez menos benefícios aos clientes. Para ficar claro: colar uma estatueta de prata de um felino famoso, ágil, bonito, feroz, inteligente no capô de um Astra ou Golf não faz dele um Jaguar... Por mais que tentemos ou tentem nos fazer acreditar nisso.
Talvez, eu é que não consegui enxergar o que OO tem por fazer e como fazer tudo na prática. Mas, sem falsa modéstia, eu não sou uma pessoa que demora para entender as coisas (eu passei em 7 vestibulares, 2 vezes em Medicina, em Londrina e Florianópolis, sempre fui um dos melhores em classe, formei-me em Administração, e desenvolvo softwares há anos, alguns funcionam na versão original desde de 1987, em Clipper).
Ou, tem alguém que não contou tudo, ou não temos uma ferramenta que entregue o que a OO está prometendo (o que considero muito provável).
E, finalmente... Para fazer testes mais fáceis, ter instalação fácil, interface de controle precisa, gostaria de usar o Access junto com o ECO, mas ele não consegue gerar os scripts de construção e manutenção das tabelas.
Alguém tem uma luz que eu possa seguir? A maioria dos Tutoriais, além de tratar pouco sobre banco de dados e persistência (todos falam de InterBase, DB2, Oracle) ficam discutindo sobre ASP.Net.
Meleca... Se é para usar ASP.Net vamos direto pra o VisualStudio, ora!
Ou será que o ECO e o Delphi 2005 deixaram de ser ferramenta para quem faz pequenos softwares, para atender o escritório de advocacia, a loja de auto-peças ou a farmácia?
Quem concordar comigo, ou souber fazer críticas que possam me educar, por favor, manifeste-se.
Ildefonso
Curtir tópico
+ 0
Responder
Posts
27/08/2005
Amfsouza
Ricardo, não estou muito por dentro do ECO de do Delphi 2005. Atualmente desenvolvo em Delphi7 pois, me atende muito bem e é estável. Compreendo sua indignação com a OO mas, não concordo. Estou ainda, caminhando na vida profissional e pretendo conquistar clientes de peso. Atualmente, trabalho para terceiros (PJ) e ralo para pagar as contas desenvolvendo aplicativos(oficialmente, tenho apenas 1)... Tenho um cliente que me paga muito pouco mas, foi o meu cliente piloto. Voltando para a OO... Considero sim nossa profissão, uma arte e com a OO isto se mostra. Creio que você esteja pensando como um usuário final, não como o criador. Para o usuário final, se foi feito as antigas, ou se com a mais moderna tecnologia, não importa...até que surjam os atrasos em manutenção ou alguma mudança. Vou contar um pouco da minha humilde história. Era Analista/programador COBOL (nesta época, mais programador) e me deparei com um novo paradigma. A visão procedural estava com os dias contados... Comecei no VB mas, o destino quis que eu parasse no Delphi. Sou autodidata e comecei a pesquisar, ler e praticar sobre OO. Gosto de aprender linguagens desenvolvendo algo. Fiz então com meu pequeno conhecimento, a primeira versão de um aplicativo comercial. Segui, o conceito OO (ou pensava que seguia...) . Enquanto isso, fui aprendendo Delphi... Neste meu primeiro projeto, segui toda a receita acadêmica para projetar (modelagem, normalização, etc..). Usando a ´OO´ (perceba as aspas), comecei minha aventura... um detalhe, encontrei muitos colegas contra a OO (até hoje). A versão 1 do meu atual sistema fic
Um grande abraço,
Atenciosamente,
Antonio Marcos
Um grande abraço,
Atenciosamente,
Antonio Marcos
Responder
Gostei + 0
27/08/2005
Amfsouza
ou uma bosta... dava muita encrenca, justamente porque não usei componentes de banco de dados (DataWare) nos forms (edits, combos, etc). Tive um trabalho gigantesco e, pouco produtivo... então, percebi a facilidade do uso dos datawares mas, conflitaria com o conceito de OO que li. Fiquei meio perdido. Deixei de lado o puritanismo e comecei a redesenhar o aplicativo. Minha visão OO já havia amadurecido e não suportava a versão 1 (que coloquei neste mesmo cliente). Despertei como arquiteto de sistemas e não apenas, programador. Antes de reiniciar o novo projeto, li e pesquisei mais uma vez sobre OO e agora também análise e projeto OO. Comecei a perceber que somos arquitetos do abstrato ou pedreiros do abstrato. Optei por ser arquiteto e então com esta nova visão, comecei a planejar e arquitetar o sistema. Reescrevi o sistema em menos tempo, a quantidade de tabelas ficou muito menor e a qualidade surpreendeu o usuário. O sistema já teve seu período de provas e nesta hora foi que o usuário percebeu a diferença do produto. (Neste cliente existem outros sistemas de terceiros). Percebi então que a arquitetura OO se destaca não só devido a beleza de gráficos e telas(que nem precisa ser a OO) mas, pela engenharia que o usuário não vê. A demanda e o tempo gasto com manutenção é mínimo.
Responder
Gostei + 0
29/08/2005
Ildefonso
Oi, Antonio Marcos. Oi, pessoal.
Entendi o que o Marcos falou, com certeza.
Mas não é isso, ainda, o que estou procurando como resposta aos meus questionamentos.
Primeiramente: lógico que penso, também, como o usuário final. Ou não venderia meus serviços. Mas é lógico que meu cliente, também, não compra softwares... Compra tranquilidade, segurança, agilidade.
Então nunca tiro da cabeça o pensamento do usuário final.
Há muito não penso como os legados do COBOL e Clipper. Há mais de uma década, Cliente, Fornecedor, etc., para mim, não é entidade, mas atributo da entidade Contatos!!! E por ai vai a abstração.
Há alguns anos eu já uso TFrames para encapsular ´objetos´.
Houve uma fase em que fiz alguns componentes, diretamente a partir do TQuery. Por exemplo, o componente TQueryContatos: ele entrava em um TForm e já ia criando os objetos TFields. Criava os campos claculados, já com formatação, tal como o campo EnderecoCompleto, pegando logradouro, número, cidade, etc. Montando e formatando de maneira fácil para eu colocar em um outro componente data-aware.
Mas isso dava muuuiitttooo trabalho para ficar mantendo: mudanças implicavam em novas compilações no pacote do componente. Compilações seguidas faziam o Delphi travar (isso até hoje).
E quando eu uso os TFrames, também, tenho problemas de crashes. Sai o do Delphi e volto... Tudo bem pelas próximas quinze compilações.
Na verdade, quanto mais visual é nossa montagem de componentes ou classes (usando TFrames, pacotes, componentes, etc.) mais lento e mais estranho fica o IDE.
Por exemplo: criei um TRIForm (modestamente, TRicardoIldefonsoForm) e coloquei no repositório.
De alguns dias para cá, quando uso herança para aproveitá-lo, o Delphi não o reconhece. Preciso entrar em uma gravação de desktop na qual só entra o .dpr, faço a abertura do formulário que está no repositório (File|New|Other... paleta forms, TRIForm [b:97693a7583]use[/b:97693a7583]), e então tudo fica ok.
Esse formulário é muito útil porque já trás componentes e ligações básicas, com o DataModule, com TFrames que sabem o que é um Contato (daí eu só informo o tipo do contato: cliente, fornecedor, funcionário, etc. ou todos).
Este TFrame, por exemplo, sabe que um Cliente pode ter dependentes. Então sabe ligar-se a uma tabela ContatosLinks, que posso usar para popular um grid.
Eu não tenho endereços na tabela de Contatos. Por quê? Por que um contato pode ter N endereços. Casa, trabalho, trabalho do cônjuge, etc.
O TFrame sabe ligar com a tabela de ContatosEnderecos, então.
Mesmo assim, está longe de ser uma orientação a objetos eficiente. Sem considerar que basta colar alguns TFrames no TRIForm que a meleca já tá feita! Tenho que salvar tudo. Sair do Delphi (que dá erro de acesso a memória) e voltar. Isso é em mais de uma máquina. Não só na minha. É só sobrecarregar o IDE com heranças de componentes que o bicho pega.
Voltando e repetindo: sem considerar a IDE que falha, os objetos não são tão objetos (ou classes) assim.
Eu não posso, por exemplo, dizer os eventos que o campo NomeCompleto carregam quando eu arrasto e solto para o form. Nem posso escolher outro componente de tela: sempre tem que ser o TDBEdit, depois tenho que ficar trocando usando o o GExpert.
No mínimo, as propriedades Published que declaro no TFrame, se fossem facilmente visíveis, poderiam poupar miuto trabalho.
De novo vem o problema: criar variável, atribuir variável. Na verdade, prestem atenção, a OO não determina espaço limitado ao código. Prega, isto sim, a separação de interface e regras, mas não diz que a interface não pode ser 100¬ OO, também, com os objetos se comunicando.
Nesta falta grave de todos os ambientes que conheço, cai também o Java, pelo qual não tenho muita simpatia. Parece que os desenvolvedores do Java queriam que todos usassem interface texto. Agora é que estão surgindo algumas coisas mais agradáveis à vista dos usuários. Mas a maioria dos sistemas fica imitando a interface SDI, onde não posso trabalhar em mais de um lugar ao mesmo tempo. Poxa! E se meu corretor está mostrando dois aparteamentos para o cliente? Preciso entrar em uma ficha, entrar na parte de fotos... Sair, sair, entrar em outra ficha e ir para as fotos... ´Qualé´?
Eu quero definir o objeto e deixá-lo fácil para ser usado da maneira mais conveniente para quem paga: o usuário final!!!
Isso tem tudo com OO. Manutenção fácil, agilidade. Mas não fui apresentado para um ambiente em que isso fique, realmente, disponível.
Entendi o que o Marcos falou, com certeza.
Mas não é isso, ainda, o que estou procurando como resposta aos meus questionamentos.
Primeiramente: lógico que penso, também, como o usuário final. Ou não venderia meus serviços. Mas é lógico que meu cliente, também, não compra softwares... Compra tranquilidade, segurança, agilidade.
Então nunca tiro da cabeça o pensamento do usuário final.
Há muito não penso como os legados do COBOL e Clipper. Há mais de uma década, Cliente, Fornecedor, etc., para mim, não é entidade, mas atributo da entidade Contatos!!! E por ai vai a abstração.
Há alguns anos eu já uso TFrames para encapsular ´objetos´.
Houve uma fase em que fiz alguns componentes, diretamente a partir do TQuery. Por exemplo, o componente TQueryContatos: ele entrava em um TForm e já ia criando os objetos TFields. Criava os campos claculados, já com formatação, tal como o campo EnderecoCompleto, pegando logradouro, número, cidade, etc. Montando e formatando de maneira fácil para eu colocar em um outro componente data-aware.
Mas isso dava muuuiitttooo trabalho para ficar mantendo: mudanças implicavam em novas compilações no pacote do componente. Compilações seguidas faziam o Delphi travar (isso até hoje).
E quando eu uso os TFrames, também, tenho problemas de crashes. Sai o do Delphi e volto... Tudo bem pelas próximas quinze compilações.
Na verdade, quanto mais visual é nossa montagem de componentes ou classes (usando TFrames, pacotes, componentes, etc.) mais lento e mais estranho fica o IDE.
Por exemplo: criei um TRIForm (modestamente, TRicardoIldefonsoForm) e coloquei no repositório.
De alguns dias para cá, quando uso herança para aproveitá-lo, o Delphi não o reconhece. Preciso entrar em uma gravação de desktop na qual só entra o .dpr, faço a abertura do formulário que está no repositório (File|New|Other... paleta forms, TRIForm [b:97693a7583]use[/b:97693a7583]), e então tudo fica ok.
Esse formulário é muito útil porque já trás componentes e ligações básicas, com o DataModule, com TFrames que sabem o que é um Contato (daí eu só informo o tipo do contato: cliente, fornecedor, funcionário, etc. ou todos).
Este TFrame, por exemplo, sabe que um Cliente pode ter dependentes. Então sabe ligar-se a uma tabela ContatosLinks, que posso usar para popular um grid.
Eu não tenho endereços na tabela de Contatos. Por quê? Por que um contato pode ter N endereços. Casa, trabalho, trabalho do cônjuge, etc.
O TFrame sabe ligar com a tabela de ContatosEnderecos, então.
Mesmo assim, está longe de ser uma orientação a objetos eficiente. Sem considerar que basta colar alguns TFrames no TRIForm que a meleca já tá feita! Tenho que salvar tudo. Sair do Delphi (que dá erro de acesso a memória) e voltar. Isso é em mais de uma máquina. Não só na minha. É só sobrecarregar o IDE com heranças de componentes que o bicho pega.
Voltando e repetindo: sem considerar a IDE que falha, os objetos não são tão objetos (ou classes) assim.
Eu não posso, por exemplo, dizer os eventos que o campo NomeCompleto carregam quando eu arrasto e solto para o form. Nem posso escolher outro componente de tela: sempre tem que ser o TDBEdit, depois tenho que ficar trocando usando o o GExpert.
No mínimo, as propriedades Published que declaro no TFrame, se fossem facilmente visíveis, poderiam poupar miuto trabalho.
De novo vem o problema: criar variável, atribuir variável. Na verdade, prestem atenção, a OO não determina espaço limitado ao código. Prega, isto sim, a separação de interface e regras, mas não diz que a interface não pode ser 100¬ OO, também, com os objetos se comunicando.
Nesta falta grave de todos os ambientes que conheço, cai também o Java, pelo qual não tenho muita simpatia. Parece que os desenvolvedores do Java queriam que todos usassem interface texto. Agora é que estão surgindo algumas coisas mais agradáveis à vista dos usuários. Mas a maioria dos sistemas fica imitando a interface SDI, onde não posso trabalhar em mais de um lugar ao mesmo tempo. Poxa! E se meu corretor está mostrando dois aparteamentos para o cliente? Preciso entrar em uma ficha, entrar na parte de fotos... Sair, sair, entrar em outra ficha e ir para as fotos... ´Qualé´?
Eu quero definir o objeto e deixá-lo fácil para ser usado da maneira mais conveniente para quem paga: o usuário final!!!
Isso tem tudo com OO. Manutenção fácil, agilidade. Mas não fui apresentado para um ambiente em que isso fique, realmente, disponível.
Responder
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)