Não consigo entender!
Pode parecer algo inútil, mas é uma simples dúvida que até hoje não foi sanada.
sou formado em ciência da computação e não é de hoje que trabalho com desenvolvimento desktop e web
Muito se lê, fala e ouve sobre Programação Orientada a Objeto.
Apesar de conseguir fazer alguns objetos, classes, comprar livros sobre o assunto, pesquisar na internet, até mesmo de maneira mais especifica, procurando materiais sobre POO com delphi, assim, bem explicito!
No ambiente delphi, onde tenho algumas empresas e os softwares desenvolvidos, funcionando e atendendo a demanda de serviço do cliente, não consigo imaginar o uso de OO nas minhas rotinas procedurais.
sei que por ex.um Tform, um datamodule, são exemplos de objetos que usamos constantemente.
Porém, já criados e funcionando.
Não consigo visualizar minhas rotinas com objetos. O mais perto de um objeto em meus projetos foi uma classe de conexão que eu criei, funciona e estou utilizando-a. Não consigo nem ver onde colocá-los, como criá-los
e material assim na internet, mostrando na prática, não acha!
não consigo ver o fator aproveitamento de códigos, já que meus clientes são diferentes um dos outros.
Se eu ficar incrementando métodos e atributos, estou perdido...
Acredito ter bastante gente com a mesma dúvida e com vergonha de perguntar.
Alguém poderia fazer um feedback comg, aliás, com todos nós pra ficar mais claro esse conceito em delphi.
sou formado em ciência da computação e não é de hoje que trabalho com desenvolvimento desktop e web
Muito se lê, fala e ouve sobre Programação Orientada a Objeto.
Apesar de conseguir fazer alguns objetos, classes, comprar livros sobre o assunto, pesquisar na internet, até mesmo de maneira mais especifica, procurando materiais sobre POO com delphi, assim, bem explicito!
No ambiente delphi, onde tenho algumas empresas e os softwares desenvolvidos, funcionando e atendendo a demanda de serviço do cliente, não consigo imaginar o uso de OO nas minhas rotinas procedurais.
sei que por ex.um Tform, um datamodule, são exemplos de objetos que usamos constantemente.
Porém, já criados e funcionando.
Não consigo visualizar minhas rotinas com objetos. O mais perto de um objeto em meus projetos foi uma classe de conexão que eu criei, funciona e estou utilizando-a. Não consigo nem ver onde colocá-los, como criá-los
e material assim na internet, mostrando na prática, não acha!
não consigo ver o fator aproveitamento de códigos, já que meus clientes são diferentes um dos outros.
Se eu ficar incrementando métodos e atributos, estou perdido...
Acredito ter bastante gente com a mesma dúvida e com vergonha de perguntar.
Alguém poderia fazer um feedback comg, aliás, com todos nós pra ficar mais claro esse conceito em delphi.
Adib Valentim
Curtidas 0
Respostas
Rodolpho Silva
27/03/2013
Olá amigo Adib Valentim,
Bem, pensar em POO na prática é muito semelhante entre as linguagens mais utilizadas no momento (C#,Java,Javascript, etc...). No Delphi, não é diferente. Tudo dependerá da arquitetura de como está projetado sua aplicação. Aí você me pergunta: "- Ah, mas como isso se dá na prática?" Eu respondo: Por exemplo, você poderia criar classes cujo o objetivo será tratar de "temas" referente a aplicação, ex: Um sistema de vendas, poderia ter as classes: TVenda, TNotaFiscal, TUsuario, TProduto, TItemDeProduto, etc... e onde em cada classe teria métodos referente ao seu conteúdo. Aí, na sua utilização, vc teria instâncias das classes (o famoso objeto) e ele seria o responsável por "orquestrar" todo o conteúdo no qual ele foi designado.
Eu por exemplo, ha bastante tempo não uso DataModules. Criei uma "fábrica" de conexão no qual eu posso conectar com qualquer BD e com qualquer componente de acesso ao BD. Tudo isso usando o conceito de Patterns (Abstract Factory) tão falado em OO.
Bem, espero que tenha ajudado!
Bem, pensar em POO na prática é muito semelhante entre as linguagens mais utilizadas no momento (C#,Java,Javascript, etc...). No Delphi, não é diferente. Tudo dependerá da arquitetura de como está projetado sua aplicação. Aí você me pergunta: "- Ah, mas como isso se dá na prática?" Eu respondo: Por exemplo, você poderia criar classes cujo o objetivo será tratar de "temas" referente a aplicação, ex: Um sistema de vendas, poderia ter as classes: TVenda, TNotaFiscal, TUsuario, TProduto, TItemDeProduto, etc... e onde em cada classe teria métodos referente ao seu conteúdo. Aí, na sua utilização, vc teria instâncias das classes (o famoso objeto) e ele seria o responsável por "orquestrar" todo o conteúdo no qual ele foi designado.
Eu por exemplo, ha bastante tempo não uso DataModules. Criei uma "fábrica" de conexão no qual eu posso conectar com qualquer BD e com qualquer componente de acesso ao BD. Tudo isso usando o conceito de Patterns (Abstract Factory) tão falado em OO.
Bem, espero que tenha ajudado!
GOSTEI 0
William
27/03/2013
Algum tempo atrás eu mesmo abri um tópico parecido e cheguei na seguinte conclusão depois de várias respostas e experiência própria.
Na minha opinião seria loucura programar 100% Orientado a Objetos usando Delphi, pois umas das caracteristicas marcantes dessa IDE é a agilidade no desenvolvimento, principalmente quando se pensa em acesso e manipulação de dados. Já desenvolvi uma pequena aplicação de banco de horas baseada em OO mas foi bem demorada hein...
Já com Java ou C# por exemplo, não existem TSQLConnection, TSQLQuery, TClientDataSet então vc tem que construir uma conexão na unha mesmo, claro sempre existem frameworks para facilitar a vida, mas nãose compara com Delphi.
Esse tipo de opinião é bem pessoal, acredito que alguns puristas podem não gostar do meu ponto de vista.
link do tópico [url]https://www.devmedia.com.br/forum/duvida-em-data-module-x-poo/412359[/url]
Na minha opinião seria loucura programar 100% Orientado a Objetos usando Delphi, pois umas das caracteristicas marcantes dessa IDE é a agilidade no desenvolvimento, principalmente quando se pensa em acesso e manipulação de dados. Já desenvolvi uma pequena aplicação de banco de horas baseada em OO mas foi bem demorada hein...
Já com Java ou C# por exemplo, não existem TSQLConnection, TSQLQuery, TClientDataSet então vc tem que construir uma conexão na unha mesmo, claro sempre existem frameworks para facilitar a vida, mas nãose compara com Delphi.
Esse tipo de opinião é bem pessoal, acredito que alguns puristas podem não gostar do meu ponto de vista.
link do tópico [url]https://www.devmedia.com.br/forum/duvida-em-data-module-x-poo/412359[/url]
GOSTEI 0
Bruno Leandro
27/03/2013
Eu nao tenho habito de utilizar muito OO, apesar de utilizar em alguns casos, o que gosto mais é de utilizar herança e bibliotecas de funções, para não ficar reinventando a roda em todo formulário.
GOSTEI 0
Adib Valentim
27/03/2013
Exatamente wllfl
eu penso que todo esse aparato técnico e verbal sobre programação orientada a objeto é com olhos para essas outras linguagens. Java, Javascript.... enfim, no delphi eu acredito tbm que não é tão interessante querermos nos aprofundar na OO. A nível de conhecimento, resolução de pequenas rotinas e simples, e até mesmo para utilização de componentes de terceiro que se baseiam na mesma. Fora isso, mesclar os dois com mais RAD pra mim ainda sai mais interessante.
é como vc disse, cada um, cada um...
minha curiosidade era apenas saber de programadores de verdade como anda esse lance de OO.
e saber se ando pensando mt fora dos padrões.
eu penso que todo esse aparato técnico e verbal sobre programação orientada a objeto é com olhos para essas outras linguagens. Java, Javascript.... enfim, no delphi eu acredito tbm que não é tão interessante querermos nos aprofundar na OO. A nível de conhecimento, resolução de pequenas rotinas e simples, e até mesmo para utilização de componentes de terceiro que se baseiam na mesma. Fora isso, mesclar os dois com mais RAD pra mim ainda sai mais interessante.
é como vc disse, cada um, cada um...
minha curiosidade era apenas saber de programadores de verdade como anda esse lance de OO.
e saber se ando pensando mt fora dos padrões.
GOSTEI 0
Thiago Jesus
27/03/2013
No meu caso programar Orientado a Objetos melhorou a qualidade do meu código, principalmente no sentido de separar responsabilidades.
Não são poucos os casos de programadores Delphi que programam instruções SQL diretamente no TForm, fazendo o conhecido código "macarronada", tornando a aplicação mais difícil de manter na medida que os requisitos do sistema mudam.
Usar orientação a objetos é mais complicado no início de um projeto, mas ajuda você a preparar o projeto para crescer naturalmente, sem grandes dores de cabeça.
Hoje em dia a Programação Orientada a Objetos e Design Patterns são muito fortes no mundo de desenvolvimento.
Eu sei apenas o básico de OO, mas hoje em dia me sinto mais confortável escrevendo código OO do que procedural.
Não são poucos os casos de programadores Delphi que programam instruções SQL diretamente no TForm, fazendo o conhecido código "macarronada", tornando a aplicação mais difícil de manter na medida que os requisitos do sistema mudam.
Usar orientação a objetos é mais complicado no início de um projeto, mas ajuda você a preparar o projeto para crescer naturalmente, sem grandes dores de cabeça.
Hoje em dia a Programação Orientada a Objetos e Design Patterns são muito fortes no mundo de desenvolvimento.
Eu sei apenas o básico de OO, mas hoje em dia me sinto mais confortável escrevendo código OO do que procedural.
GOSTEI 0