Na prática, POO ou Estruturada???
Olá colegas, a um tempo atraz, fiz algumas entrevistas de emprego para trabalhar com Delphi, fiz entrevista para trabalhar em projetos em orgãos públicos em lugares muito bons, e sempre tive uma surpresa, com o Delphi aonde eu ia eles trabalhavam com programação estuturada...... eu pensava e a POO???? e as inumeras vantegens da POO que todos falam??? atualmente trabalho numa empresa onde utilizamos Delphi e somente POO............na prática, no dia a dia de vcs, qual vcs mais usam, POO ou estruturada?????
Quartieri
Curtidas 0
Respostas
Titanius
05/11/2006
Vantagens!?!?
Sinceridade? Eu acho POO um saco, e muito ruim, é claro que tens suas vantagens, mas está longe de ser mil maravilhas, o delphi não foi projetado para se programar em OO, deve ser por isso que ele é tão ruim de ser mexer em OO, talvez linguagens que foram preparadas para tal seja melhor, em delphi é um problema.
Tem vários problemas, alguns deles: Demora e dificuldade na codificação e depurução.
Você tem que fazer tudo na mão, os inserts, edits, e mandar os dados pros Edits e afins.. é claro que alguns componentes vem com componentes de acesso DataWare, o que por sua vez é retórico, usar um componente OO com componente Procedural pra mexer com ele...
Bem, eu li num livro, esqueci o nome, que a programacao OO pode ser muito boa, se empregada desde o inicio, e desde que a equipe faça tudo certinho, analise, requisitos e etc... nao adianta somente programar em OO, seu sistema ficará muito pior.
Ah.. e li também que um dos problemas da OO, ´alem dos problemas de codificacao e depuracao, o alto consuimo de memoria do sistema...
bem, é isso...
[]s
Sinceridade? Eu acho POO um saco, e muito ruim, é claro que tens suas vantagens, mas está longe de ser mil maravilhas, o delphi não foi projetado para se programar em OO, deve ser por isso que ele é tão ruim de ser mexer em OO, talvez linguagens que foram preparadas para tal seja melhor, em delphi é um problema.
Tem vários problemas, alguns deles: Demora e dificuldade na codificação e depurução.
Você tem que fazer tudo na mão, os inserts, edits, e mandar os dados pros Edits e afins.. é claro que alguns componentes vem com componentes de acesso DataWare, o que por sua vez é retórico, usar um componente OO com componente Procedural pra mexer com ele...
Bem, eu li num livro, esqueci o nome, que a programacao OO pode ser muito boa, se empregada desde o inicio, e desde que a equipe faça tudo certinho, analise, requisitos e etc... nao adianta somente programar em OO, seu sistema ficará muito pior.
Ah.. e li também que um dos problemas da OO, ´alem dos problemas de codificacao e depuracao, o alto consuimo de memoria do sistema...
bem, é isso...
[]s
GOSTEI 0
Macario
05/11/2006
Ah.. e li também que um dos problemas da OO, ´alem dos problemas de codificacao e depuracao, o alto consuimo de memoria do sistema...
[]s
Nao conhecia este fato.
GOSTEI 0
Titanius
05/11/2006
Li isso num livro.... :D
Engenharia de Software.. esqueci o autor, um de capa verde!
[]s
Engenharia de Software.. esqueci o autor, um de capa verde!
[]s
GOSTEI 0
Quartieri
05/11/2006
e vc usa qual no seu dia a dia, POO ou Estruturada?
GOSTEI 0
Macario
05/11/2006
e vc usa qual no seu dia a dia, POO ou Estruturada?
Ola.
Eu uso Estruturada. 8)
GOSTEI 0
Quartieri
05/11/2006
Up :D
GOSTEI 0
Brunocantelli
05/11/2006
eu utilizo a POO, ao contrário do que todos pensam, delphi foi preparado para ser híbrido, não foi projetado para ser melhor com estruturada ou melhor com orientação a objetos, ele foi sim é projetado para ser híbrido ! As únicas linguagens que são 100¬ orientadas a objetos são SmallTalk e Eiffel, ao contrário do que as pessoas pensam, java é híbrido também. Eu vejo lá minhas vantagens e desvantagens em se trabalhar com a POO, vantagens em amadurecimento do sistema, vantagens separar onde esta cada coisa e principalmente na manutenção e tempo de teste, onde usando POO a manutenção é mais fácil e o tempo de testes é muito mais rápido ! VOcê garante uma qualidade maior do software no final ! Só pelo fato de se utilizar o delphi ja esta se fazendo orientação a objetos, quando se arrasta por exemplo um componente qualquer da paleta de componentes, o delphi nada mais faz do que instanciar ao ser formulário um objeto qual seja.
GOSTEI 0
Edibertoalves
05/11/2006
Atualmente no sistema que desenvolvo, utilizo o paradigma de desenvolvimento estruturado. No próximo sistema que estamos projetando desenvolveremos OO. Abrangendo todo o ciclo de desenvolvimento de software.
Concordo o que o Bruno escreveu... vc pode desenvolver OO utilizando tanto os componentes DBAware quanto os Não-DBAware... mas se for para ter um domínio completo do desenvolvimento prefiro usar os Não-DBAware, justamente para ter a certeza de 100¬ de aonde os meus objetos estão sendo manipulados.
Mais uma coisa que tb concordo é a concorrência com outras linguagens. É uma heresia comparar o Delphi com outras linguagens; especialmente com o Java. É primordial que a pessoa que venha comparar o Delphi com outras linguagens que procure saber, corra atrás e pesquise muuuuuito sobre as vantagens/desvantagens do Object Pascal x outras linguagens.
Abraços
Ediberto
Concordo o que o Bruno escreveu... vc pode desenvolver OO utilizando tanto os componentes DBAware quanto os Não-DBAware... mas se for para ter um domínio completo do desenvolvimento prefiro usar os Não-DBAware, justamente para ter a certeza de 100¬ de aonde os meus objetos estão sendo manipulados.
Mais uma coisa que tb concordo é a concorrência com outras linguagens. É uma heresia comparar o Delphi com outras linguagens; especialmente com o Java. É primordial que a pessoa que venha comparar o Delphi com outras linguagens que procure saber, corra atrás e pesquise muuuuuito sobre as vantagens/desvantagens do Object Pascal x outras linguagens.
Abraços
Ediberto
GOSTEI 0
Yallebr
05/11/2006
Ola pesssoal,
Acredito que a grande maioria das pessoas que desenvolvem Delphi, desenvolvem Estruturada por alguns motivos:
1) No geral (vejam que coloquei ´no geral´), a qualidade da mão de obra de Delphi é inferior a de algumas outras linguagens, pelo fator que Delphi é muito simples de desenvolver e muito rápido. Então existem vários ´programadores´ que escolheram Delphi apenas por esse fator, não sendo pessoas que acompanham a tecnologia ou estudam melhores métodos ou processos de Desenvolvimento.
2) É uma IDE que vem de antes da OO (apenas na versao 3 passou a ser OO com a entrada de Interfaces)
3) Não existe a Cultura OO no Delphi.
Eu particularmente desenvolvo apenas OO em Delphi, um único motivo. [b:b52af113af]Não faz sentido desenvolver estruturado[/b:b52af113af]. OO tem muito mais produtividade, mais manutenabilidade e vc pode utilizar várias boas práticas e padrões do mercado, como padrões de projeto e a inquestionável UML.
Acredito que a OO consome mais recurso do compilador, claro. Afinal existirão heranças, polimorfismos que o compilador deverá procurar classes acima ou abaixo. Enquanto na estruturada isso não existe, é o codigo e pronto. [b:b52af113af]Agora vc está fazendo um sistema de tempo crítico? [/b:b52af113af] Então será que seu cliente vai importar de espera 0.0001 (chute de tempo, mas sei que é insignificante) segundo a mais para fazer uma operação?
Então o único sentido na minha visão de desenvolver estruturado em Delphi é falta de capacitação profissional e não a questão do Delphi ser ou não ´feito´ para o mundo OO.
Abraços
Acredito que a grande maioria das pessoas que desenvolvem Delphi, desenvolvem Estruturada por alguns motivos:
1) No geral (vejam que coloquei ´no geral´), a qualidade da mão de obra de Delphi é inferior a de algumas outras linguagens, pelo fator que Delphi é muito simples de desenvolver e muito rápido. Então existem vários ´programadores´ que escolheram Delphi apenas por esse fator, não sendo pessoas que acompanham a tecnologia ou estudam melhores métodos ou processos de Desenvolvimento.
2) É uma IDE que vem de antes da OO (apenas na versao 3 passou a ser OO com a entrada de Interfaces)
3) Não existe a Cultura OO no Delphi.
Eu particularmente desenvolvo apenas OO em Delphi, um único motivo. [b:b52af113af]Não faz sentido desenvolver estruturado[/b:b52af113af]. OO tem muito mais produtividade, mais manutenabilidade e vc pode utilizar várias boas práticas e padrões do mercado, como padrões de projeto e a inquestionável UML.
Acredito que a OO consome mais recurso do compilador, claro. Afinal existirão heranças, polimorfismos que o compilador deverá procurar classes acima ou abaixo. Enquanto na estruturada isso não existe, é o codigo e pronto. [b:b52af113af]Agora vc está fazendo um sistema de tempo crítico? [/b:b52af113af] Então será que seu cliente vai importar de espera 0.0001 (chute de tempo, mas sei que é insignificante) segundo a mais para fazer uma operação?
Então o único sentido na minha visão de desenvolver estruturado em Delphi é falta de capacitação profissional e não a questão do Delphi ser ou não ´feito´ para o mundo OO.
Abraços
GOSTEI 0
Fabiano Góes
05/11/2006
Ola pesssoal,
Então o único sentido na minha visão de desenvolver estruturado em Delphi é falta de capacitação profissional e não a questão do Delphi ser ou não ´feito´ para o mundo OO.
Abraços
concordo com o amigo: yallebr.
Tanto que se repararem os post sobre OO são muito poucos comentados nnca tem uma bom continuidade.
bom, sou bem novato em Delphi em relação a muitos aqui, pois trabalho com Delphi apenas a 5 anos, portanto se eu falar alguma besteira podem me corrigir pois assim posso aprender mais com o colegas.
Apesar do meu pouco tempo tenho feito muitas pesquisas e estudado muito POO e pelo pouco que sei já cheguei a conclusão de inumeras vantagens da POO sobre PP, dentre elas vou citar algumas:
- a reutilização de código( nao ´copiar´ e ´colar´ ).
- manutenabilidade.
- certeza de 100¬ de aonde os meus objetos estão sendo manipulados.
e depois de montar uma estrutura legal OO tudo se torna muito produtivo, que é um ponto muito consideravel no desenvolvimento.
E o Delphi possibilita uma boa pratica de POO.
Agora quanto a velha questão ´qual linguagem é melhor´, acho que quem faz da linguagem boa ou ruim são os programadores e essa questão jamais chegará a uma conclusão.
abraço a todos !!!
GOSTEI 0
Rjun
05/11/2006
É uma heresia comparar o Delphi com outras linguagens; especialmente com o Java.
Fiquei curioso. Onde está a heresia?
[quote:40742c95d3=´Fabiano Góes´]a reutilização de código( nao ´copiar´ e ´colar´ ).
[/quote:40742c95d3]
Código reutilizável é possivel em programação estruturada.
O problema é que tem muito programador que só por que usa classes, herança e outros conceitos acha que está programando OO.
GOSTEI 0
Edibertoalves
05/11/2006
Rogério,
No meu ponto de vista comparação entre 2 ou mais linguagens chega a um ponto de heresia sim! Cada linguagem tem sua característica, seus pontos fortes e pontos fracos. Já vi e me decepcionei com os confrontos entre ´Delphianos´ e ´Javanistas´; no final o que vai reger serão os cacoetes trocados entre uns e outros. De um lado Delphi (RAD) contra Java (Cross-Platform)...
Não se pode haver comparação onde o EGO fala mais alto e sim encontrar uma melhor ferramenta para que satisfaça a necessidade.
Abraços
Ediberto
No meu ponto de vista comparação entre 2 ou mais linguagens chega a um ponto de heresia sim! Cada linguagem tem sua característica, seus pontos fortes e pontos fracos. Já vi e me decepcionei com os confrontos entre ´Delphianos´ e ´Javanistas´; no final o que vai reger serão os cacoetes trocados entre uns e outros. De um lado Delphi (RAD) contra Java (Cross-Platform)...
Não se pode haver comparação onde o EGO fala mais alto e sim encontrar uma melhor ferramenta para que satisfaça a necessidade.
Abraços
Ediberto
GOSTEI 0
Rjun
05/11/2006
Rogério,
No meu ponto de vista comparação entre 2 ou mais linguagens chega a um ponto de heresia sim! Cada linguagem tem sua característica, seus pontos fortes e pontos fracos. Já vi e me decepcionei com os confrontos entre ´Delphianos´ e ´Javanistas´; no final o que vai reger serão os cacoetes trocados entre uns e outros. De um lado Delphi (RAD) contra Java (Cross-Platform)...
Não se pode haver comparação onde o EGO fala mais alto e sim encontrar uma melhor ferramenta para que satisfaça a necessidade.
Abraços
Ediberto
Concordo com cada virgula. Quando se entra nesse tipo de discussão, só encontramos fundamentalistas, tanto de um lado quanto de outro.
GOSTEI 0
Denis
05/11/2006
olá,
Acho que a gente tem que avaliar e usar o melhor. Nem sempre POO é vantagem e nem sempre Estruturada é vantagem.
Acho que o ideal é usar o que tem de melhor nas duas formas. Eu uso um pouquinho das duas
Acho que a gente tem que avaliar e usar o melhor. Nem sempre POO é vantagem e nem sempre Estruturada é vantagem.
Acho que o ideal é usar o que tem de melhor nas duas formas. Eu uso um pouquinho das duas
GOSTEI 0
Felipeiw
05/11/2006
Ola,
Esse assunto é muito interessante, ja li varios topicos onde se compara delphi com java, e tenho visto que para comecar a programar em java, necessariamente tem que aprender OO, e com delphi a historia na maioria, digo na maioria, dos casos, comeca a aprender, colocando os componentes no form, e recheando seus eventos, foi assim na faculdade, foi assim em alguns cursos que vi, diante disso, quero dizer que o inicio do aprendizado é muito diferente nessas duas linguagens, enquanto em uma a enfase é na OO na outra e no arrastar e soltar, adoro delphi, tudo que quero fazer consigo, muitas vezes com a ajuda desse otimo forum, que tem pessoas capacitadas que doam seus valiosos minutos para nos ajudar. Mas na mh opiniao, ou pela mh falta de capacidade em encontrar, nao tenho exemplos e nem textos que me ensinem a utilizar OO em delphi, e digo exemplos utilizaveis no dia a dia e nao exemplos abstratos, sei que pedi mais do que sugeri, mas para quem esta afim de aprender nada melhor do que pedir pra quem sabe de verdade.
Abs
Esse assunto é muito interessante, ja li varios topicos onde se compara delphi com java, e tenho visto que para comecar a programar em java, necessariamente tem que aprender OO, e com delphi a historia na maioria, digo na maioria, dos casos, comeca a aprender, colocando os componentes no form, e recheando seus eventos, foi assim na faculdade, foi assim em alguns cursos que vi, diante disso, quero dizer que o inicio do aprendizado é muito diferente nessas duas linguagens, enquanto em uma a enfase é na OO na outra e no arrastar e soltar, adoro delphi, tudo que quero fazer consigo, muitas vezes com a ajuda desse otimo forum, que tem pessoas capacitadas que doam seus valiosos minutos para nos ajudar. Mas na mh opiniao, ou pela mh falta de capacidade em encontrar, nao tenho exemplos e nem textos que me ensinem a utilizar OO em delphi, e digo exemplos utilizaveis no dia a dia e nao exemplos abstratos, sei que pedi mais do que sugeri, mas para quem esta afim de aprender nada melhor do que pedir pra quem sabe de verdade.
Abs
GOSTEI 0
Cesar Romero
05/11/2006
Vou separar 2 ítens importantes, para que possa dar minha opinião:
1) Delphi como IDE - Toda vez q eu falar Delphi estarei me referindo ao ambiente.
O Delphi, foi criado para tornar o desenvolvimento de sistemas mais rápido, para que quando você arrastar componentes no formulário algum código já seja gerado, e com o auxilio do object inspector o desenvolvedor seja guiado na programação Orientada a Eventos.
2) Object Pascal - linguagem de progração.
O Object Pascal, que a Borland a partir do Delphi 7, passou a chamar de Delphi Language, é uma linguagem que suporta programação procedural e programação oritentada a objetos.
Desenvolver sistemas com o delphi são orientados a objeto sim, mas as facilidades de ligação do código com os componentes através dos eventos, mais os recursos limitados, mais os prazos sempre apertados, induzem aos poucos deixar muito código junto, do ´jeitão´ procedural, que para reutilização estariam melhor em outras classes, há também a a falta de preocupação em seguir padrões, mas isto eu vejo como sendo uma cultura, ou falta de, no Brasil, por que o mesmo problema acontece em qualquer linguagem.
E por que isto é um problema?
A hierarquia da VCL, faz com que internamente muito código desnecessário seja adicionado aos seus objetos, então a solução é não utilizar a VCL, e a implementação disto com Interfaces, ajuda a manter o código reutilizável e mais limpo.
Um pequeno exemplo disto, está em um post que eu escrevi, [url]http://blogs.liws.com.br/cesar/?p=23[/url], para mostrar quando escrever seus objetos ou herdar de TComponent, e mostra que neste caso o ganho de performace é incrivelmente superior.
O que faltam são frameworks implementados com os recursos OO que foram adicionados a partir do Delphi 3, que atendam todas as etapas do desenvolvimento, Regra de Negócio, Persistência e Interface do Usuário, e que tornem o desenvolvimento OOP tão produtivo quanto o RAD padrão do Delphi. Por isto eu desenvolvi Frameworks próprios implementando todas estas necessidades, atualmente estou finalizando a parte de interface do usuário (MVP - Model View Presenter) e ainda esta semana, começo a fazer os ´wizards´ que deixarão o desenvolvimento OO com meu framework do jeito RAD. :)
Se alguém tiver interesse em ver, baixar, ver fontes o link do projeto é http://jazz.liws.com.br
Fiquem a vontade em postar suas dúvidas, ainda esta semana disponibilizarei uma nova versão com todos os exemplos refeitos, onde a interface será com os objetos MVP e nos forms não terá nenhum código.
E é claro que se o livro é sobre RAD ele não vai defender que outro jeito de programar seja melhor, senão porque alguém compraria o livro, mas no mínimo deveria ser imparcial.
Todo sistema que você faz com OO pode fazer procedural e vice-versa, a qualidade vai do talento de cada programador combinado com as ferramentas disponíveis.
1) Delphi como IDE - Toda vez q eu falar Delphi estarei me referindo ao ambiente.
O Delphi, foi criado para tornar o desenvolvimento de sistemas mais rápido, para que quando você arrastar componentes no formulário algum código já seja gerado, e com o auxilio do object inspector o desenvolvedor seja guiado na programação Orientada a Eventos.
2) Object Pascal - linguagem de progração.
O Object Pascal, que a Borland a partir do Delphi 7, passou a chamar de Delphi Language, é uma linguagem que suporta programação procedural e programação oritentada a objetos.
Desenvolver sistemas com o delphi são orientados a objeto sim, mas as facilidades de ligação do código com os componentes através dos eventos, mais os recursos limitados, mais os prazos sempre apertados, induzem aos poucos deixar muito código junto, do ´jeitão´ procedural, que para reutilização estariam melhor em outras classes, há também a a falta de preocupação em seguir padrões, mas isto eu vejo como sendo uma cultura, ou falta de, no Brasil, por que o mesmo problema acontece em qualquer linguagem.
O que eu acho que seja um problema
, e que vejo outros desenvolvedores no newsgroup oodesign da borland também comentar, é que o modelo utilizado foi implementado no Delphi 1, a VCL, as diversas especializações de TDataSet, e a borland tem como compromisso manter compatibilidade.E por que isto é um problema?
A hierarquia da VCL, faz com que internamente muito código desnecessário seja adicionado aos seus objetos, então a solução é não utilizar a VCL, e a implementação disto com Interfaces, ajuda a manter o código reutilizável e mais limpo.
Um pequeno exemplo disto, está em um post que eu escrevi, [url]http://blogs.liws.com.br/cesar/?p=23[/url], para mostrar quando escrever seus objetos ou herdar de TComponent, e mostra que neste caso o ganho de performace é incrivelmente superior.
O que faltam são frameworks implementados com os recursos OO que foram adicionados a partir do Delphi 3, que atendam todas as etapas do desenvolvimento, Regra de Negócio, Persistência e Interface do Usuário, e que tornem o desenvolvimento OOP tão produtivo quanto o RAD padrão do Delphi. Por isto eu desenvolvi Frameworks próprios implementando todas estas necessidades, atualmente estou finalizando a parte de interface do usuário (MVP - Model View Presenter) e ainda esta semana, começo a fazer os ´wizards´ que deixarão o desenvolvimento OO com meu framework do jeito RAD. :)
Se alguém tiver interesse em ver, baixar, ver fontes o link do projeto é http://jazz.liws.com.br
Fiquem a vontade em postar suas dúvidas, ainda esta semana disponibilizarei uma nova versão com todos os exemplos refeitos, onde a interface será com os objetos MVP e nos forms não terá nenhum código.
Alguém falou ai, que leu em um livro de capa verde que programação OO é ruim ou algo parecido
, acho que o autor deste livro deveria deixar claro que isto deve ser opinião pessoal dele ou se ele estiver falando de um modo geral, deveria pesquisar mais antes de publicar o livro e eu não indicaria a ninguém este livro, não pq ele falou mal de OO, mas pq não é uma postura que eu aprovo.E é claro que se o livro é sobre RAD ele não vai defender que outro jeito de programar seja melhor, senão porque alguém compraria o livro, mas no mínimo deveria ser imparcial.
Todo sistema que você faz com OO pode fazer procedural e vice-versa, a qualidade vai do talento de cada programador combinado com as ferramentas disponíveis.
Vi também comentário de que OO usa mais memória
, isto é a maior furada, também vai da qualidade do código de quem escreve o sistema, tenho certeza que esta cheio de programadores que criam todos os forms automaticamente no .DPR o que consome muita memória, desenvolver software profissional não é fazer planilha de excel, tem de ter projeto e na implementação procurar fazer o melhor possível, isto depende de nós programadores.As threads sobre OO não evoluem
, eu já participei de mais de uma, e sempre a thread para por que não são mais enviados comentários ou dúvidas, mais uma vez me ponho a disposição para cotinuar uma thread de qualidade sobre OO.Atualmente eu desenvolvo somente OO
, tenho sistemas inteiros em 3 camadas, tenho exemplos, sempre leciono cursos de OOP com Delphi para empresas, se alguém quiser conhecer mais sobre isto é só entrar em contato.GOSTEI 0
Quartieri
05/11/2006
Cesarliws....
Show de bola seu texto, se puder me mandar material sobre POO e Delphi eu ficaria muito agradecido : leoquartieri@hotmail.com
Show de bola seu texto, se puder me mandar material sobre POO e Delphi eu ficaria muito agradecido : leoquartieri@hotmail.com
GOSTEI 0
Cesar Romero
05/11/2006
Ola Quartieri,
Há textos, exemplos e código do framework nos links do site do projeto:
http://jazz.liws.com.br
Os principais são:
wiki: http://www.liws.com.br/wiki
blog: http://blogs.liws.com.br/cesar
Repositório subversion: http://code.google.com/p/jazz-sdk
Lista de discussão: http://groups.google.com/group/jazz-sdk
Em alguns dias terei mais material detalhado é só acompanhar estes sites, e qualquer dúvida fique a vontade em entrar em contato.
[]s
Há textos, exemplos e código do framework nos links do site do projeto:
http://jazz.liws.com.br
Os principais são:
wiki: http://www.liws.com.br/wiki
blog: http://blogs.liws.com.br/cesar
Repositório subversion: http://code.google.com/p/jazz-sdk
Lista de discussão: http://groups.google.com/group/jazz-sdk
Em alguns dias terei mais material detalhado é só acompanhar estes sites, e qualquer dúvida fique a vontade em entrar em contato.
[]s
GOSTEI 0
Quartieri
05/11/2006
:D
Valeu!!!
Valeu!!!
GOSTEI 0
Brunocantelli
05/11/2006
bom galera, na verdade, a POO também não é o PARAÍSO NA TERRA. Eu trabalho tanto com estruturado quanto com POO. E assim, estruturado é bom em projetos pequenos e quando não há promessa de melhorias no sistema, e o custo que o cliente deseja arcar é pouco ( tive um caso desses, onde analisando o dono da empresa, sabia que ele não ia querer pagar para manutenções no sistema e preferiria fazer a empresa não mudar para continuar trabalhando com o software sem custo adicional,m não ia trabalhar mais ganhando a mesma coisa para não ser utilizado mais pra frente). Quem vai fazer todos as fases do modelo ROUP se não for ganhar bem o suficiente para isso ? A POO gera mais custo, e inicialmente ela é mais cara, porém, ao longo do tempo este custo é compensado e se transforma em economia de recursos e qualidade de software, visto que mudanças impactarão menos ( claro que sem um bom analista este fato não é possível, um erro de entrevista pode trazer a tona uma catástrofe no sistema). A estruturada é mais facilmente corrompível a bugs e a ter uma qualidade final e de manutebilidade menor, porém é mais rápida de se fazer e bem mais barata.
Mas enfim, cada caso é um caso, e repito a todos que pensem o contrário !
[size=18:b28b98e1d5][color=red:b28b98e1d5]´JAVA É HÍBRIDO E NÃO 100¬ ORIENTADO A OBJETOS, POR ISSO NÃO COMPAREM DELPHI COM JAVA, CADA UMA TEM SUAS CARACTERÍSTICAS, E AMBAS SÃO EXCELENTES EM TODOS OS ASPECTOS, AS ÚNICAS LINGUAGENS 100¬ ORIENTADAS A OBJETOS SÃO SMALL TALK E EIFELL´.[/color:b28b98e1d5][/size:b28b98e1d5]
Mas enfim, cada caso é um caso, e repito a todos que pensem o contrário !
[size=18:b28b98e1d5][color=red:b28b98e1d5]´JAVA É HÍBRIDO E NÃO 100¬ ORIENTADO A OBJETOS, POR ISSO NÃO COMPAREM DELPHI COM JAVA, CADA UMA TEM SUAS CARACTERÍSTICAS, E AMBAS SÃO EXCELENTES EM TODOS OS ASPECTOS, AS ÚNICAS LINGUAGENS 100¬ ORIENTADAS A OBJETOS SÃO SMALL TALK E EIFELL´.[/color:b28b98e1d5][/size:b28b98e1d5]
GOSTEI 0
Cesar Romero
05/11/2006
brunocantelli,
POO não gera mais custo não, na minha empresa só gerou economia pois aumentou a reutilização de código e reduziu a manutenção.
Qualquer sistema pode ser OOP ou estruturado, tanto faz, mas usar o RUP é outra história, só usa quem quiser e pode pagar, exite o XP, ICONIX o AGILE, todas são metodologias boas cada uma com suas características.
PS:
Não entendo pq o Outdoor ai na sua mensagem.
POO não gera mais custo não, na minha empresa só gerou economia pois aumentou a reutilização de código e reduziu a manutenção.
Qualquer sistema pode ser OOP ou estruturado, tanto faz, mas usar o RUP é outra história, só usa quem quiser e pode pagar, exite o XP, ICONIX o AGILE, todas são metodologias boas cada uma com suas características.
PS:
Não entendo pq o Outdoor ai na sua mensagem.
GOSTEI 0
Fabiano Góes
05/11/2006
cesarliws, você já tem algum curso de OO ?
se tiver me mande informações: fabianogoes@ig.com.br
se tiver me mande informações: fabianogoes@ig.com.br
GOSTEI 0
Cesar Romero
05/11/2006
Fabiano Góes,
Temos sim, na semana que vem estarei lecionando para uma empresa de SP, na semana seguinte estarei em Tubarão-SC e na primeira semana de Dezembro em Francisco Beltrão-PR.
Estou viajando, mas até o início da próxima semana eu envio informações do curso para o seu email.
[]s
Temos sim, na semana que vem estarei lecionando para uma empresa de SP, na semana seguinte estarei em Tubarão-SC e na primeira semana de Dezembro em Francisco Beltrão-PR.
Estou viajando, mas até o início da próxima semana eu envio informações do curso para o seu email.
[]s
GOSTEI 0
Yallebr
05/11/2006
Citação:
Vi também comentário de que OO usa mais memória
,
=============
isto é a maior furada, também vai da qualidade do código de quem escreve o sistema, tenho certeza que esta cheio de programadores que criam todos os forms automaticamente no .DPR o que consome muita memória, desenvolver software profissional não é fazer planilha de excel, tem de ter projeto e na implementação procurar fazer o melhor possível, isto depende de nós programadores.
Olá cesarliws,
Vou discordar de você, a programação OO exige mais do compilador e também em tempo de execução.
Quando vc trabalha estruturado, vc tem todo seu código em um procedimento ou em um ´Botão´ assim será executado apenas aquele código.
Quando se trata de OO aquele código pode ser herença de 20 classes com 5 interfaces e por ai vai. Nesse ponto terá que ser feita uma varredura para saber onde é a implementação do código, tento que verificar inclusive se é sobrecarga, se é virtual e outras diretivas.
Não estou falando que isso vai atrapalhar o desempenho do programa, eu utilizo OO. Mas que exige maior processamente isso não há dúvida. Existe inclusive 2 diretivas que podemos utilizar em nossos métodos que são, ´Virtual e Dinamica´ onde (não em 100¬ dos casos depende da estrutura das classes) a virtual é mais rápida e a dinamica consome menos memória.
Abraços.
GOSTEI 0
Cesar Romero
05/11/2006
yallebr, você tem certeza que tem ´noção´ do que você está falando?
Acho primeiro que vc deve rever seus conceitos:
- um botão está em um form, um form é um objeto, como qualquer outro.
- Quando você cria o form (só relembrando, que é um objeto e ainda tem ´resorces´) é instanciado na memória.
- Então se você tem um método que é o ´ButtonClick´ ou em um outro objeto qualquer, o código só sera executado quando você chamar.
Por favor se você acha que ainda assim esta certo, leia este artigo
http://blogs.liws.com.br/cesar/?p=23
baixe o programa exemplo compile e teste você mesmo, nele comparo objetos que eu fiz com TComponents.
Isto não nada a ver, desculpe mesmo, acho que você deveria estudar o assunto.
Por acaso você já leu o help dos componentes do delphi?
A maior justificativa é exatamente o oposto do que você está falando.
Você já viu a hierarquia da VCL?
- TButton tem 7 níveis de hierarquia,
- TForm e TDBEdit tem 8 níveis,
TComponent implementa:
- Integração com a IDE
- Intercepta mensagens do Windows
- COM
Sério leia o artigo que eu sugeri, teste o programa exemplo e ai pense novamente se seus conceitos estão corretos, só pra vc comparar veja os tempos de criar e destruir objetos simples e derivados de TComponent:
Isto não nada a ver, desculpe mesmo, acho que você deveria estudar o assunto.
Por acaso você já leu o help dos componentes do delphi?
A maior justificativa é exatamente o oposto do que você está falando.
Você já viu a hierarquia da VCL?
- TButton tem 7 níveis de hierarquia,
- TForm e TDBEdit tem 8 níveis,
TComponent implementa:
- Integração com a IDE
- Intercepta mensagens do Windows
- COM
Sério leia o artigo que eu sugeri, teste o programa exemplo e ai pense novamente se seus conceitos estão corretos, só pra vc comparar veja os tempos de criar e destruir objetos simples e derivados de TComponent:
Pelas informações que você passou, a sua forma de utilizar OO, não tem nada a ver com o que estamos falando nesta thread.
Métodos dinamicos e virtuais são utilizados para que se possa sobrescrever métodos em classes descendentes, apenas isto, ´herança´, cada um com uma otimização diferente, dependendo do objetivo.
Já perguntei se você já leu o help do Delphi?
No diretório sources do delphi tem os fontes de todos os componentes que você usa, dá uma olhada nestes fontes, se tiver alguma dúvida em entender fica a vontade em postar suas dúvidas, com certeza após fazer isto seus sistemas serão melhores, você só tem a ganhar.
[]s
Vou discordar de você, a programação OO exige mais do compilador e também em tempo de execução.
Quando vc trabalha estruturado, vc tem todo seu código em um procedimento ou em um ´Botão´ assim será executado apenas aquele código.
Acho primeiro que vc deve rever seus conceitos:
- um botão está em um form, um form é um objeto, como qualquer outro.
- Quando você cria o form (só relembrando, que é um objeto e ainda tem ´resorces´) é instanciado na memória.
- Então se você tem um método que é o ´ButtonClick´ ou em um outro objeto qualquer, o código só sera executado quando você chamar.
Por favor se você acha que ainda assim esta certo, leia este artigo
http://blogs.liws.com.br/cesar/?p=23
baixe o programa exemplo compile e teste você mesmo, nele comparo objetos que eu fiz com TComponents.
Quando se trata de OO aquele código pode ser herença de 20 classes com 5 interfaces e por ai vai. Nesse ponto terá que ser feita uma varredura para saber onde é a implementação do código, tento que verificar inclusive se é sobrecarga, se é virtual e outras diretivas.
Isto não nada a ver, desculpe mesmo, acho que você deveria estudar o assunto.
Por acaso você já leu o help dos componentes do delphi?
A maior justificativa é exatamente o oposto do que você está falando.
Você já viu a hierarquia da VCL?
- TButton tem 7 níveis de hierarquia,
- TForm e TDBEdit tem 8 níveis,
TComponent implementa:
- Integração com a IDE
- Intercepta mensagens do Windows
- COM
Sério leia o artigo que eu sugeri, teste o programa exemplo e ai pense novamente se seus conceitos estão corretos, só pra vc comparar veja os tempos de criar e destruir objetos simples e derivados de TComponent:
Tempo
Memória para criar para destruir
10.000 TComponent : 4488 K 10.906 ms 31.516 ms
10.000 TNamedObject: 4396 K 32 ms 281 ms
Não estou falando que isso vai atrapalhar o desempenho do programa, eu utilizo OO. Mas que exige maior processamente isso não há dúvida. Existe inclusive 2 diretivas que podemorá que ser feita uma varredura para saber onde é a implementação do código, tento que verificar inclusive se é sobrecarga, se é virtual e outras diretivas.
Isto não nada a ver, desculpe mesmo, acho que você deveria estudar o assunto.
Por acaso você já leu o help dos componentes do delphi?
A maior justificativa é exatamente o oposto do que você está falando.
Você já viu a hierarquia da VCL?
- TButton tem 7 níveis de hierarquia,
- TForm e TDBEdit tem 8 níveis,
TComponent implementa:
- Integração com a IDE
- Intercepta mensagens do Windows
- COM
Sério leia o artigo que eu sugeri, teste o programa exemplo e ai pense novamente se seus conceitos estão corretos, só pra vc comparar veja os tempos de criar e destruir objetos simples e derivados de TComponent:
Tempo
Memória para criar para destruir
10.000 TComponent : 4488 K 10.906 ms 31.516 ms
10.000 TNamedObject: 4396 K 32 ms 281 ms
Não estou falando que isso vai atrapalhar o desempenho do programa, eu utilizo OO. Mas que exige maior processamente isso não há dúvida. Existe inclusive 2 diretivas que podemos utilizar em nossos métodos que são, ´Virtual e Dinamica´ onde (não em 100¬ dos casos depende da estrutura das classes) a virtual é mais rápida e a dinamica consome menos memória.
Pelas informações que você passou, a sua forma de utilizar OO, não tem nada a ver com o que estamos falando nesta thread.
Métodos dinamicos e virtuais são utilizados para que se possa sobrescrever métodos em classes descendentes, apenas isto, ´herança´, cada um com uma otimização diferente, dependendo do objetivo.
Já perguntei se você já leu o help do Delphi?
No diretório sources do delphi tem os fontes de todos os componentes que você usa, dá uma olhada nestes fontes, se tiver alguma dúvida em entender fica a vontade em postar suas dúvidas, com certeza após fazer isto seus sistemas serão melhores, você só tem a ganhar.
[]s
GOSTEI 0
Yallebr
05/11/2006
Olá cesarliws,
2 razões retiradas de material oficial da Borland que a OO tem pequena perda de performance.
Acho que vc entrou em muito detalhe, detalhe e mais detalhe para mostrar alguns conhecimentos gerias desconexos de Delphi, mas não falou nada de OO.
Sem entrar no mérito de vc ler o Help, ou qualquer documentacao nao vou entrar. Apenas certifico que tenho conhecimento dessa leitura para ser [b:6b9bf605ff]Certificado em Delphi[/b:6b9bf605ff], onde em torno de 10¬ da prova é OO e mais uns 10¬ acredito que é referente a Hierarquia da VCL, entao nao sei de onde vem SUA tão falada leitura do HELP.
Essas citações feitas não tem nada haver com o assunto, são conhecimentos superficiais de Delphi. Acho que vc não entende a idéia da OO (pode ser que entende algumas classes Delphi),
Peço por favor para discutirmos com material fundamentado, e não apresente apenas opinião pessoal infundada para não virar discussão de opinião pessoal e sim uma discussão técnica.
[b:6b9bf605ff][i:6b9bf605ff]Fonte. Material de Certificação da Borland Apostila Básica, pag 171.[/i:6b9bf605ff][/b:6b9bf605ff]
Agora vamos para a engenharia de software.
Conforme está em negrito. Como o desempenho de uma solução genérica pode ser melhor que uma solução específica? (o que é uma ideia da OO, é fazer um código mais genérico para ser reutítizável.)
Ultima citação do texto da Borland (veja ele com atenção), [b:6b9bf605ff]os códigos iniciais de um projeto OO tendem a ser maiores[/b:6b9bf605ff] (ou seja, simples, mais linhas para serem executadas). Porém ganha-se em reutilização. Mas nao estamos falando de reutilização e sim performance
Então para vc entender, faça uma pergunta para vc mesmo. [b:6b9bf605ff]Como tenho mais códigos (por ser uma solução genérica) e tenho uma execução mais rápida? [/b:6b9bf605ff]
Agora para finalizar com a última citação da Borland.
[b:6b9bf605ff]Fonte: Criação de componentes - Material Oficial da Borland pag 28, 30[/b:6b9bf605ff]
Então esse texto mostra que existe uma necessidade de criar um VMT ou DMT para uma classe para determinar os ascendentes, então isso além de consumir mais memória leva tempo de processamento. Para um método é analisado a VMT.
Ou seja... Métodos estáticos são pouco mais rápidos. claro.
[b:6b9bf605ff]Se estamos programando estruturado não possuímos todos os ´procedimentos estáticos´? Ou seja, não precisa visualizar a VMT a cada chamada de um método / procedimento basta executar o procedimento[/b:6b9bf605ff]
Resumindo:
Códigos OO tendem a ser mais genéricos e também existe a necessidade de “analisar os ascendentes em Run Time isso claro leva tempo, então existe uma pequena perda de performance.
Peço que não entre em comentários desnecessários como Tform é uma classe, Tbuttom tem X ascendentes, e outras coisas. Vc está tentando mostrar informações iniciantes que estão disponível facilmente no F1 e que não estão relacionadas a performance.
Abraços
2 razões retiradas de material oficial da Borland que a OO tem pequena perda de performance.
Acho que vc entrou em muito detalhe, detalhe e mais detalhe para mostrar alguns conhecimentos gerias desconexos de Delphi, mas não falou nada de OO.
Sem entrar no mérito de vc ler o Help, ou qualquer documentacao nao vou entrar. Apenas certifico que tenho conhecimento dessa leitura para ser [b:6b9bf605ff]Certificado em Delphi[/b:6b9bf605ff], onde em torno de 10¬ da prova é OO e mais uns 10¬ acredito que é referente a Hierarquia da VCL, entao nao sei de onde vem SUA tão falada leitura do HELP.
Acho primeiro que vc deve rever seus conceitos:
- um botão está em um form, um form é um objeto, como qualquer outro.
- Quando você cria o form (só relembrando, que é um objeto e ainda tem ´resorces´) é instanciado na memória.
- Então se você tem um método que é o ´ButtonClick´ ou em um outro objeto qualquer, o código só sera executado quando você chamar.
Essas citações feitas não tem nada haver com o assunto, são conhecimentos superficiais de Delphi. Acho que vc não entende a idéia da OO (pode ser que entende algumas classes Delphi),
Peço por favor para discutirmos com material fundamentado, e não apresente apenas opinião pessoal infundada para não virar discussão de opinião pessoal e sim uma discussão técnica.
Modular programming is a composable rather than decomposable. This means that [b:6b9bf605ff]tying together small, generic[/b:6b9bf605ff] parts is the ke process to creating programs.
The essence of modular programming insists that every time you solve a problem, that you should solve it is as generically as possible.(...)
[b:6b9bf605ff]While it indeed takes a little longer to create your initial programs (becouse you are solving the problems generically),[/b:6b9bf605ff] (...)
[b:6b9bf605ff][i:6b9bf605ff]Fonte. Material de Certificação da Borland Apostila Básica, pag 171.[/i:6b9bf605ff][/b:6b9bf605ff]
Agora vamos para a engenharia de software.
Conforme está em negrito. Como o desempenho de uma solução genérica pode ser melhor que uma solução específica? (o que é uma ideia da OO, é fazer um código mais genérico para ser reutítizável.)
Ultima citação do texto da Borland (veja ele com atenção), [b:6b9bf605ff]os códigos iniciais de um projeto OO tendem a ser maiores[/b:6b9bf605ff] (ou seja, simples, mais linhas para serem executadas). Porém ganha-se em reutilização. Mas nao estamos falando de reutilização e sim performance
Então para vc entender, faça uma pergunta para vc mesmo. [b:6b9bf605ff]Como tenho mais códigos (por ser uma solução genérica) e tenho uma execução mais rápida? [/b:6b9bf605ff]
Agora para finalizar com a última citação da Borland.
The benefit is that any attempt to execute a virtual method requires just a simple look ito a VMT regardless of which ancestor actyally implemented the method. (leia isso com atenção por favor)
[b:6b9bf605ff] Static methods do not go through a lookp process at runtime so so THEY EXECUTE SLIGHTLY FASTER (..)
[/b:6b9bf605ff]
[b:6b9bf605ff]Fonte: Criação de componentes - Material Oficial da Borland pag 28, 30[/b:6b9bf605ff]
Então esse texto mostra que existe uma necessidade de criar um VMT ou DMT para uma classe para determinar os ascendentes, então isso além de consumir mais memória leva tempo de processamento. Para um método é analisado a VMT.
Ou seja... Métodos estáticos são pouco mais rápidos. claro.
[b:6b9bf605ff]Se estamos programando estruturado não possuímos todos os ´procedimentos estáticos´? Ou seja, não precisa visualizar a VMT a cada chamada de um método / procedimento basta executar o procedimento[/b:6b9bf605ff]
Resumindo:
Códigos OO tendem a ser mais genéricos e também existe a necessidade de “analisar os ascendentes em Run Time isso claro leva tempo, então existe uma pequena perda de performance.
Peço que não entre em comentários desnecessários como Tform é uma classe, Tbuttom tem X ascendentes, e outras coisas. Vc está tentando mostrar informações iniciantes que estão disponível facilmente no F1 e que não estão relacionadas a performance.
Abraços
GOSTEI 0
Yallebr
05/11/2006
Apenas completando,
Está parecendo que sou contra OO, sou totalmente a favor e acredito em poucos projetos que tem vantagem de ser estruturado.
Na minha opinião a grande vantagem da OO e Reutilização de Código e manutenabilidade. Além de facilitar utilizar padrões de projetos e permitir utilizar UML.
O que implica em desenvolvimento mais rápido e corte de custo.
Meu texto acima está apenas mostrando a que existe uma perda de performance (mesmo que seja pequena), e é apenas para explicar o texto do amigo cesarliws que disse que que opinião dele não existe.
Abraços.
Está parecendo que sou contra OO, sou totalmente a favor e acredito em poucos projetos que tem vantagem de ser estruturado.
Na minha opinião a grande vantagem da OO e Reutilização de Código e manutenabilidade. Além de facilitar utilizar padrões de projetos e permitir utilizar UML.
O que implica em desenvolvimento mais rápido e corte de custo.
Meu texto acima está apenas mostrando a que existe uma perda de performance (mesmo que seja pequena), e é apenas para explicar o texto do amigo cesarliws que disse que que opinião dele não existe.
Abraços.
GOSTEI 0
Cesar Romero
05/11/2006
Yallebr, há formas de escrever sistemas bons e ruins em OO, procedural seja como for, mas a forma que você está colocando é que todos sistemas OO serão lentos.
Está levando em conta que seu sistema terá apenas o código que você escrever sem levar em conta o código da VCL, que não importa se é em OO ou procedural vão junto no executável,
então você está dizendo que:
1) VCL não é composta de código genérico?
Tem certeza disto?
2) Os Componentes da VCL não tem métodos Genéricos e/ou sobrescritos e para eles não são criados VMT ou DMT? (usando o que vc argumenta deixar lento)
Certificado não faz de você um bom profissional, é apenas mais um passo que alguém que deseja ser bom profissional pode seguir, não vou entrar em méritos de ´qualificações´ pq também não é o motivo desta thread.
Está levando em conta que seu sistema terá apenas o código que você escrever sem levar em conta o código da VCL, que não importa se é em OO ou procedural vão junto no executável,
então você está dizendo que:
1) VCL não é composta de código genérico?
Tem certeza disto?
2) Os Componentes da VCL não tem métodos Genéricos e/ou sobrescritos e para eles não são criados VMT ou DMT? (usando o que vc argumenta deixar lento)
Certificado não faz de você um bom profissional, é apenas mais um passo que alguém que deseja ser bom profissional pode seguir, não vou entrar em méritos de ´qualificações´ pq também não é o motivo desta thread.
GOSTEI 0
Rjun
05/11/2006
Bom, já que o tópico meio que saiu do caminho, quero fazer uma pergunta. Essa semana estou visitando vários tópicos sobre OO, principalmente em fóruns sobre Java. Tem um colunista que mantém um site (www.fragmentals.com.br) muito bom. É verdade que mais da metada das coisas que ele fala é de dificil compreensão, mas com um pouco de esforço da pra pegar alguma coisa. Bom, minha dúvida é a seguinte: li em foruns e em um blog que não me lembro qual agora, que a Herança é algo que deve ser evitado, pois pode causar mais problemas do que solução, e que na verdade deveria-se usar composição. Quero saber a opinião do pessoal sobre isso.
GOSTEI 0
Cesar Romero
05/11/2006
Rjun,
Se o que eles postarem se refere a Java e for relacionado ao código gerado pelo Java não sei dizer, pois meus conhecimentos em Java se limitam a linguem e não a VM, mas acho que o que estas pessoas devem se referir é que a maioria das pessoas confundem quando usar herança ou quando usar uma composição ou agregação.
Por exemplo: TPessoa, TEmpresa, TFuncionario, TFornecedor
eu nunca faria uma herança de TPessoa para TFuncionario, ou de TFornecedor que poderia (mas não deveria) ser especialização de TPessoa e TEmpresa.
Por que funcionário se refere a um cargo que uma pessoa está ´atuando´ naquele momento. No caso de forncedor ele pode ao mesmo tempo ser Cliente também.
Em outras palavras são pessoas ou empresas atuando como Fornecedor, Cliente, Usuário...
O que eu uso para diferenciar é:
- O que você é
- O que você faz
Em casos como este o Pattern ´Rules´ se encaixa direitinho, pois você pode adicionar ou remove-las de acordo com os ´relacionamentos´ acontecem.
Alguns autores até deixam claro na dúvida entre herança e composição use composição.
Eu penso que você deve analisar exatemente o que é esta nova classe, e só fazer a herança se for realmente uma especialização.
Nestes casos acho que p o ´Pattern Rule´ pode se encaixar direitinho, li um bom artigo sobre ele implementado em Delphi, se eu achar o Link posto aqui.
[]s
Se o que eles postarem se refere a Java e for relacionado ao código gerado pelo Java não sei dizer, pois meus conhecimentos em Java se limitam a linguem e não a VM, mas acho que o que estas pessoas devem se referir é que a maioria das pessoas confundem quando usar herança ou quando usar uma composição ou agregação.
Por exemplo: TPessoa, TEmpresa, TFuncionario, TFornecedor
eu nunca faria uma herança de TPessoa para TFuncionario, ou de TFornecedor que poderia (mas não deveria) ser especialização de TPessoa e TEmpresa.
Por que funcionário se refere a um cargo que uma pessoa está ´atuando´ naquele momento. No caso de forncedor ele pode ao mesmo tempo ser Cliente também.
Em outras palavras são pessoas ou empresas atuando como Fornecedor, Cliente, Usuário...
O que eu uso para diferenciar é:
- O que você é
- O que você faz
Em casos como este o Pattern ´Rules´ se encaixa direitinho, pois você pode adicionar ou remove-las de acordo com os ´relacionamentos´ acontecem.
Alguns autores até deixam claro na dúvida entre herança e composição use composição.
Eu penso que você deve analisar exatemente o que é esta nova classe, e só fazer a herança se for realmente uma especialização.
Nestes casos acho que p o ´Pattern Rule´ pode se encaixar direitinho, li um bom artigo sobre ele implementado em Delphi, se eu achar o Link posto aqui.
[]s
GOSTEI 0
Rjun
05/11/2006
Cesar
Concordo com o que você falou e vai bem na linha dos foruns que visitei. As vezes se usa herança para economizar algumas linhas de código e quando é necessário alterar alguma coisa na superclasse, os efeitos nas subclasses podem ser catastróficos.
Aqui esta o [url=http://blog.caelum.com.br/2006/10/14/como-nao-aprender-orientacao-a-objetos-heranca/]link[/url] do artigo sobre herança que havia mencionado.
Concordo com o que você falou e vai bem na linha dos foruns que visitei. As vezes se usa herança para economizar algumas linhas de código e quando é necessário alterar alguma coisa na superclasse, os efeitos nas subclasses podem ser catastróficos.
Aqui esta o [url=http://blog.caelum.com.br/2006/10/14/como-nao-aprender-orientacao-a-objetos-heranca/]link[/url] do artigo sobre herança que havia mencionado.
GOSTEI 0
Cesar Romero
05/11/2006
Rjun,
É exatamente daquilo que eu estava falando, o exemplo do gato e cachorro são ótimos.
Por razões como estas que eu prefiro programar com Interfaces, estas tem sido de grande ajuda no design dos meus sistemas, até mesmo listas eu prefiro não herdar, e sim encapsular internamente.
[]s
É exatamente daquilo que eu estava falando, o exemplo do gato e cachorro são ótimos.
Por razões como estas que eu prefiro programar com Interfaces, estas tem sido de grande ajuda no design dos meus sistemas, até mesmo listas eu prefiro não herdar, e sim encapsular internamente.
[]s
GOSTEI 0
Rjun
05/11/2006
Cesar
Sem querer abusar, mas já abusando, gostaria de discutir algo com você. Eu tento desenvolver OO em C#. Na verdade tudo começou com a necessidade de desenvolver um aplicativo para Windows CE que iria acessar banco de dados SQL Server e SQL Server CE. Partimos para .NET com C. Utilizei como base o exemplo Pet Shop 3.0 da Microsoft, onde se usa uma divisão em 3 camadas. Nesse exemplo, na camada de regra de negócios temos dois projetos, um onde temos objetos de negócio com propriedades e construtores vazios (objeto de dados) e outro projeto, onde estão as regras de negócio.
Bom, durante a implantação, caimos numa armadilha, no caso de relacionamento de objetos. Aqui está o texto da thead que postei no MSDN, mas até agora sem sucesso de resposta.
Se você puder me dar uma luz ficaria grato. Em Delphi, você também usa esses tipos de objeto?
Sem querer abusar, mas já abusando, gostaria de discutir algo com você. Eu tento desenvolver OO em C#. Na verdade tudo começou com a necessidade de desenvolver um aplicativo para Windows CE que iria acessar banco de dados SQL Server e SQL Server CE. Partimos para .NET com C. Utilizei como base o exemplo Pet Shop 3.0 da Microsoft, onde se usa uma divisão em 3 camadas. Nesse exemplo, na camada de regra de negócios temos dois projetos, um onde temos objetos de negócio com propriedades e construtores vazios (objeto de dados) e outro projeto, onde estão as regras de negócio.
Bom, durante a implantação, caimos numa armadilha, no caso de relacionamento de objetos. Aqui está o texto da thead que postei no MSDN, mas até agora sem sucesso de resposta.
Consideremos o exemplo PET SHOP 3.0, da Microsoft. Nele temos uma aplicação dividida em 3 camadas. Temos um projeto com os objetos de negócios (os Info da vida, ex. AccountInfo, AddressInfo, etc), e um outro projeto com as regras de negócio.
Vamos nos concentrar no Info. Por exemplo, OrderInfo possui como propriedade AddressInfo e na carga do banco de dados feito pela DAL, o SELECT que retornar um Order especifico retorna também as informações para preencher o objeto Address de Order. Agora, imaginemos que Address tivesse uma propriedade que apontasse para outro objeto e que esse objeto apontasse para outro. Quero saber que quando eu der a carga em um Order especifico eu teria que carregar todos os objetos ligados a ele, direta ou indiretamente?
Eu pensei em fazer Lazy Loading, mas utilizando essa arquitetura, não daria pois não conseguiria referenciar o projeto com as regras de negocio a partir do Model, a não ser que eu criasse dentro do Model, uma conexão com a camada de BD usando os Factorys.
Se você puder me dar uma luz ficaria grato. Em Delphi, você também usa esses tipos de objeto?
GOSTEI 0
Cesar Romero
05/11/2006
Sim eu faço isto, e utilizo LazyLoad, que está implementado no Jazz.
Eu apenas não entendi por que você utiliza 2 projetos.
O que eu faço é algo mais ou menos assim:
Objetos de negócio são simples, sem regra de negócio e NÃO sabem nada mesmo da persistencia.
As regras de negócios são implementadas em outros objetos (no mesmo projeto) minha implementação é ´inspirada´ no Pattern Proxy e Aspectos, simulando uma ´Injeção´ de código.
A Persitância é implementada no OPF, em que eu crio uma
quando vai salvar ou recuperar objetos eu apenas chamo
O Gerenciamento de quando a regra de negócio é feita de acordo com o que está acontecendo, para tal, eu criei um Gerenciar, onde os Objetos de validação são registrados indicando quando devem ser executados, por exemplo:
- Validação de INPUT
- Antes de Salvar
- em algum método ´pré-definido´ Before/After ´Setter´
O LazyLoad acontece automaticamente, só precisa definir no mapeamento que será
carregado com LazyLoad, caso contrario vc precisará chamar o Session.Load() para
o atributo.
Ta ficando interessante este ´post´ :)[/code]
Eu apenas não entendi por que você utiliza 2 projetos.
O que eu faço é algo mais ou menos assim:
Objetos de negócio são simples, sem regra de negócio e NÃO sabem nada mesmo da persistencia.
As regras de negócios são implementadas em outros objetos (no mesmo projeto) minha implementação é ´inspirada´ no Pattern Proxy e Aspectos, simulando uma ´Injeção´ de código.
A Persitância é implementada no OPF, em que eu crio uma
var ActiveSession: ISession begin ActiveSession:= NewSession(TDBXFirebirdMechanism); end
quando vai salvar ou recuperar objetos eu apenas chamo
ActiveSession.Load(AccountList);
O Gerenciamento de quando a regra de negócio é feita de acordo com o que está acontecendo, para tal, eu criei um Gerenciar, onde os Objetos de validação são registrados indicando quando devem ser executados, por exemplo:
- Validação de INPUT
- Antes de Salvar
- em algum método ´pré-definido´ Before/After ´Setter´
O LazyLoad acontece automaticamente, só precisa definir no mapeamento que será
carregado com LazyLoad, caso contrario vc precisará chamar o Session.Load() para
o atributo.
Ta ficando interessante este ´post´ :)[/code]
GOSTEI 0
Rjun
05/11/2006
Cesar
Utilizo dois projetos devido ao fato do exemplo Pet Shop utilizar dois projetos. Como não tinha um norte, copiei a estrutura do exemplo da MS. Então, consideremos um cadastro de cliente. Você teria um objeto de negócio (CLIENTEINFO, segundo o exemplo PET SHOP) e um objeto que contem as regras de negócio (CLIENTE, segundo o exemplo PET SHOP). Na classe CLIENTE estão as regras de gerem o cliente e nele que é feita a instacialização do DAO atráves da pattern Factory. A ideia é essa ou estou falando besteira?
Utilizo dois projetos devido ao fato do exemplo Pet Shop utilizar dois projetos. Como não tinha um norte, copiei a estrutura do exemplo da MS. Então, consideremos um cadastro de cliente. Você teria um objeto de negócio (CLIENTEINFO, segundo o exemplo PET SHOP) e um objeto que contem as regras de negócio (CLIENTE, segundo o exemplo PET SHOP). Na classe CLIENTE estão as regras de gerem o cliente e nele que é feita a instacialização do DAO atráves da pattern Factory. A ideia é essa ou estou falando besteira?
GOSTEI 0
Cesar Romero
05/11/2006
Eu não conheço este exemplo, a ´arquitetura´ que eu criei é baseana nas necessidades aqui da empresa e em experiências anteriores.
Eu acho que o modelo que você está seguinte pode dar certo sim, mas como você nunca implementou ficam muitas duvidas, eu mesmo passei muito por isto.
Lendo a sua última explicação, este modelo se parece muito com o que eu estou fazendo, só que você está usando 2 projetos, não sei o impacto que pode ter no desenvolvimento, o que eu vejo é a necessidade de aplicar a regra de negócio no momento certo, então o responsável por isto, tem de saber como instanciar este objeto cliente, é o que o meu ´Gerenciador´ faz, apensar de não ser, tem um ´jeitão´ de Aspect - ´AOP´.
Acho que você está no caminho, só não posso dar certezas por que não conheço detalhes do ambiente, mas pelas suas explicações, pode estar certo que se parece com o modelo que eu uso.
[]s
Eu acho que o modelo que você está seguinte pode dar certo sim, mas como você nunca implementou ficam muitas duvidas, eu mesmo passei muito por isto.
Lendo a sua última explicação, este modelo se parece muito com o que eu estou fazendo, só que você está usando 2 projetos, não sei o impacto que pode ter no desenvolvimento, o que eu vejo é a necessidade de aplicar a regra de negócio no momento certo, então o responsável por isto, tem de saber como instanciar este objeto cliente, é o que o meu ´Gerenciador´ faz, apensar de não ser, tem um ´jeitão´ de Aspect - ´AOP´.
A ideia é essa ou estou falando besteira?
Acho que você está no caminho, só não posso dar certezas por que não conheço detalhes do ambiente, mas pelas suas explicações, pode estar certo que se parece com o modelo que eu uso.
[]s
GOSTEI 0
Rjun
05/11/2006
Cesar
Acontece que nessa solução, com 2 projetos, fica dificil de fazer lazy loading ja que o objeto de negocio não pode instanciar o objeto de regra de négocio. Pelo menos não diretamente.
Outra coisa, ter objetos que so tem propriedades e ter uma classe que manipule esses objetos não foge da ideia de OO? De uma olhada nesse [url=http://www.guj.com.br/posts/list/23735.java] tópico no GUJ[/url].
Acontece que nessa solução, com 2 projetos, fica dificil de fazer lazy loading ja que o objeto de negocio não pode instanciar o objeto de regra de négocio. Pelo menos não diretamente.
Outra coisa, ter objetos que so tem propriedades e ter uma classe que manipule esses objetos não foge da ideia de OO? De uma olhada nesse [url=http://www.guj.com.br/posts/list/23735.java] tópico no GUJ[/url].
GOSTEI 0
Cesar Romero
05/11/2006
Fica muito complicado você alterar estes projetos e fazê-los apenas 1, ou transformar um deles em uma biblioteca?
Algumas partes do meu projeto funcionam assim:
No Servidor tenho a Interface e a Implementação do Objeto
No Cliente apenas a Interface
Quando o Cliente precisa de um objeto, ele pede para o servidor a instância, consigo isto apenas a partir da interface, que faz a solicitação para o Invoker.
É claro, tem mecanismos no meio que recebem o stream do servidor e criam uma instância no cliente:
- tem Factory no Servidor, que cria a instância que tem a lógica, e
- tem Factory no Cliente que cria a instância que terá somente os atributos.
Não li toda a thread, mas o pouco que li tive a impressão que eles estão se prendendo a um puritanismo quando falam que se você separar atributos de implementação é contra principios do OO, há casos em que você deve abstrair algum código.
Não vejo pq em uma classe de transporte de dados, você obrigatóriamente adicionar lógica, é desperdicio de recursos.
Mas se quer manter uma ´compatibilidade´ com o conceito OO que eles se dizem naquela thread, pode implementar seus objetos com o Pattern Proxy, criando Objetos simples (somente dados) e especializando-os (Os Proxy) adicionando o código.
Mas viajando nos recursos OO, penso que se isto fosse uma completa ´verdade´ o Pattern Visitor não existiria, e há varios outros patterns que cumprem este papel, mesmo objetivo, mas implementados de forma diferente.
Um conceito que implementei no Jazz VTF é o de DataPacket.
Os Objetos tem atributos simples (String, Integer, Currency, etc..), mas internamente seus Fields são dos tipos (TStringType, TIntegerType, TCurrencyType, etc...)
Quando o OPF recebe um objeto, ele ´retira´ do objeto o DataPacket que contém os ´Fields´ dos tipos ´Value Types´ e passa este DataPacket para o objeto que está no servidor com a regra de negócio, que já conhece a estrutura deste DataPacket e sabe o que fazer com ele.
Acho que o modelo de desenvolvimento que estamos falando é diferente do que o que eles estão discutindo, vai muito além de criar objetos e sava-los no banco de dados, então é necessário uma adaptação para que se tenha mais eficiência e qualidade.
[]s
Algumas partes do meu projeto funcionam assim:
No Servidor tenho a Interface e a Implementação do Objeto
No Cliente apenas a Interface
Quando o Cliente precisa de um objeto, ele pede para o servidor a instância, consigo isto apenas a partir da interface, que faz a solicitação para o Invoker.
É claro, tem mecanismos no meio que recebem o stream do servidor e criam uma instância no cliente:
- tem Factory no Servidor, que cria a instância que tem a lógica, e
- tem Factory no Cliente que cria a instância que terá somente os atributos.
Outra coisa, ter objetos que so tem propriedades e ter uma classe que manipule esses objetos não foge da ideia de OO?
Não li toda a thread, mas o pouco que li tive a impressão que eles estão se prendendo a um puritanismo quando falam que se você separar atributos de implementação é contra principios do OO, há casos em que você deve abstrair algum código.
Não vejo pq em uma classe de transporte de dados, você obrigatóriamente adicionar lógica, é desperdicio de recursos.
Mas se quer manter uma ´compatibilidade´ com o conceito OO que eles se dizem naquela thread, pode implementar seus objetos com o Pattern Proxy, criando Objetos simples (somente dados) e especializando-os (Os Proxy) adicionando o código.
Mas viajando nos recursos OO, penso que se isto fosse uma completa ´verdade´ o Pattern Visitor não existiria, e há varios outros patterns que cumprem este papel, mesmo objetivo, mas implementados de forma diferente.
Um conceito que implementei no Jazz VTF é o de DataPacket.
Os Objetos tem atributos simples (String, Integer, Currency, etc..), mas internamente seus Fields são dos tipos (TStringType, TIntegerType, TCurrencyType, etc...)
Quando o OPF recebe um objeto, ele ´retira´ do objeto o DataPacket que contém os ´Fields´ dos tipos ´Value Types´ e passa este DataPacket para o objeto que está no servidor com a regra de negócio, que já conhece a estrutura deste DataPacket e sabe o que fazer com ele.
Acho que o modelo de desenvolvimento que estamos falando é diferente do que o que eles estão discutindo, vai muito além de criar objetos e sava-los no banco de dados, então é necessário uma adaptação para que se tenha mais eficiência e qualidade.
[]s
GOSTEI 0
Rjun
05/11/2006
Cesar
Abusando mais um pouco, quando você instancia os objetos da regra de negocio, você instancia dois objetos? Por exemplo, o objeto de negocio Cliente e objeto de regra de negocios Cliente? Ou você usa algo parecido com Façade?
Abusando mais um pouco, quando você instancia os objetos da regra de negocio, você instancia dois objetos? Por exemplo, o objeto de negocio Cliente e objeto de regra de negocios Cliente? Ou você usa algo parecido com Façade?
GOSTEI 0
Rjun
05/11/2006
César
Então suas validações ficam todas nas classes de regra de negócios? Por exemplo, considere uma classe ItemPedido e que tenha como propriedade Quantidade. Se existe uma regra que diz que a quantidade não pode ser maior que 5, isso fica no objeto de negócio ou na classe de regras de negócio?
Então suas validações ficam todas nas classes de regra de negócios? Por exemplo, considere uma classe ItemPedido e que tenha como propriedade Quantidade. Se existe uma regra que diz que a quantidade não pode ser maior que 5, isso fica no objeto de negócio ou na classe de regras de negócio?
GOSTEI 0
Cesar Romero
05/11/2006
Rjun,
Revendo meu último post, vi que pode gerar confusão, então para exclarecer, o objeto tem os métodos definidos na Interface, só não tem a implementação, que fica no objeto ´real´.
Quanto a forma que eu faço, eu procuro balancear, não coloco todos os métodos no servidor.
- rotinas de validação de INPUT ficam no cliente.
- rotinas que não exigem acesso a banco de dados geralmente ficam no cliente tambem.
Este tipod e metodologia é algo que evolui sempre e toda vez que precisar otimizar acabamos tento de procurar outros meios para obter o mesmo resultado de forma mais eficiente.
[]s
Revendo meu último post, vi que pode gerar confusão, então para exclarecer, o objeto tem os métodos definidos na Interface, só não tem a implementação, que fica no objeto ´real´.
Quanto a forma que eu faço, eu procuro balancear, não coloco todos os métodos no servidor.
- rotinas de validação de INPUT ficam no cliente.
- rotinas que não exigem acesso a banco de dados geralmente ficam no cliente tambem.
Este tipod e metodologia é algo que evolui sempre e toda vez que precisar otimizar acabamos tento de procurar outros meios para obter o mesmo resultado de forma mais eficiente.
[]s
GOSTEI 0