Cadastro Orientado a objeto
Pessoal, boa tarde...
Por favor, alguem teria um fonte simples de cadastro, só que feito com orientacao a objeto (gerando classe, propriedade, e tudo mais) ou mesmo indicar algum site que possa ter esse fonte. Estou tentando construir um objeto, mas estou tendo muita dificuldade.
Obrigado
Por favor, alguem teria um fonte simples de cadastro, só que feito com orientacao a objeto (gerando classe, propriedade, e tudo mais) ou mesmo indicar algum site que possa ter esse fonte. Estou tentando construir um objeto, mas estou tendo muita dificuldade.
Obrigado
Rod001
Curtidas 0
Respostas
Aroldo Zanela
20/01/2005
Colega,
A ´coisa´ é até bem simples, entretanto, quando chegar na parte de persistência, realmente tem algumas novidades.
Muita coisa sobre OO, você encontra no: www.oodesgin.com.br
A ´coisa´ é até bem simples, entretanto, quando chegar na parte de persistência, realmente tem algumas novidades.
Muita coisa sobre OO, você encontra no: www.oodesgin.com.br
GOSTEI 0
Dopi
20/01/2005
Já li muito sobre trazer a POO para o dia a dia como no exemplo citado...
Mas na prática nunca vi funcionar... Nunca vi um sistema comercial nascer de uma ferramenta puramente UML... na minha opiniao a distancia entre o projeto e a implementação é enorme.... Simplesmente porque algumas coisas são mais complicadas ou menos práticas se seguir a OO a risca...
Mas para cadastros.. voce pode fazer um Form padrão com toda a funcionalidade contendo um Navigator, botoes para Inc, alt, exc, etc... e apenas um DataSource já ligado esses componentes...
No codigo do form sempre se referencia ao ´Datasource.DataSet´ quando precisar de algum metodo/propriedade do DataSet... (Isso porque nao sabemos qual DataSet será ligado a ele futuramente)
Agora vc pode salvar esse Form no ObjectRepository e fazer herança dele sempre que precisar de um Form com as mesmas caracteristicas...
Vá em File, New, Onther e escolha o seu Form e apenas ajuste a propriedade DataSet do DataSource que o Form já possui para uma dos DataSets do sistema que vc está desenvolvendo...
Eu uso isso, e a produtividade é incrivel....
Se não me engano na Revista ClubDelphi que fala sobre um sistema chamado DataCar eles explicam essa técnica em detalhes...
Mas na prática nunca vi funcionar... Nunca vi um sistema comercial nascer de uma ferramenta puramente UML... na minha opiniao a distancia entre o projeto e a implementação é enorme.... Simplesmente porque algumas coisas são mais complicadas ou menos práticas se seguir a OO a risca...
Mas para cadastros.. voce pode fazer um Form padrão com toda a funcionalidade contendo um Navigator, botoes para Inc, alt, exc, etc... e apenas um DataSource já ligado esses componentes...
No codigo do form sempre se referencia ao ´Datasource.DataSet´ quando precisar de algum metodo/propriedade do DataSet... (Isso porque nao sabemos qual DataSet será ligado a ele futuramente)
Agora vc pode salvar esse Form no ObjectRepository e fazer herança dele sempre que precisar de um Form com as mesmas caracteristicas...
Vá em File, New, Onther e escolha o seu Form e apenas ajuste a propriedade DataSet do DataSource que o Form já possui para uma dos DataSets do sistema que vc está desenvolvendo...
Eu uso isso, e a produtividade é incrivel....
Se não me engano na Revista ClubDelphi que fala sobre um sistema chamado DataCar eles explicam essa técnica em detalhes...
GOSTEI 0
Technos
20/01/2005
Realmente como o amigo citou acima, a produtividade com o exemplo dado por ele é incrivel.
Já vi muito sobre POO, pouco em delphi, mas paguei na faculdade uma cadeira de JAVA, e admito. Não gostei nada de Java, menos ainda de POO (Talves por que eu tenha visto uma nova linguagem com um novo método de programação talvez), mas prefiro ficar com o bom e velho método procedural. Mas faz esse lance de herança cara, é muito massa mesmo, mas fica de olho, que mesmo depois de criado um projeto por exemplo, e vc alterar o formulário ancestral, se vc abrir projetos antigos e compilá-los, com as alterações no formulario padrão, se vc nao se ligar, dá um BUG miserável.
É só prestar atenção.
Já vi muito sobre POO, pouco em delphi, mas paguei na faculdade uma cadeira de JAVA, e admito. Não gostei nada de Java, menos ainda de POO (Talves por que eu tenha visto uma nova linguagem com um novo método de programação talvez), mas prefiro ficar com o bom e velho método procedural. Mas faz esse lance de herança cara, é muito massa mesmo, mas fica de olho, que mesmo depois de criado um projeto por exemplo, e vc alterar o formulário ancestral, se vc abrir projetos antigos e compilá-los, com as alterações no formulario padrão, se vc nao se ligar, dá um BUG miserável.
É só prestar atenção.
GOSTEI 0
Rod001
20/01/2005
Ola pessoal.
Tenho lido bastante tambem sobre orientacao a objetos e quando fiz um curso de UML, disseram que realmente nao eh um negocio facil, principalmente por estarmos abtuados com o procedural.
Eu estou tentando quebrar o vicio do estrutural, mas realmente nao eh coisa facil.
Porem, o que indicam os artigos eh que a orientacao a objeto eh muito aconselhada em projetos de grande porte, principalmente pela redução de codificacao, quando o projeto eh bem estruturado e pela manutencao do mesmo.
Não eh um negocio que se investe hoje e tem um retorno rapido. Eh um retorno demorado, porem depois do investimento, vem sua compensação. Estou utlizando o Enterprise Architect para fazer UML e ele consegue gerar um pouco de codigo, criando pelo menos as classes do delphi, juntamente com os seus tipos de atributos (private, public, protected, etc), mas na hora de fazer a codificação ainda encontro dificuldades. No procedural, jah utilizo herança de forms, repositorios, etc, mas ainda parece que não eh isso o que a orientacao a objeto tem de melhor.Quando desenvolvemos um objeto, tem algumas caracteristicas como: ser atomico, ter alta coesao, ter minima dependencia, transmissao de msg, etc ... efim ... não estou conseguindo desenvolver isso. Acho que isso complica um pouco mais quando tenta-se desenvolver um projeto em POO quando se utiliza n-camadas. Se o client?server tradicional jah é complicado, imagina-se o resto.
Por isso pedi ajuda aos colegas da lista.
Muito Obrigado
Tenho lido bastante tambem sobre orientacao a objetos e quando fiz um curso de UML, disseram que realmente nao eh um negocio facil, principalmente por estarmos abtuados com o procedural.
Eu estou tentando quebrar o vicio do estrutural, mas realmente nao eh coisa facil.
Porem, o que indicam os artigos eh que a orientacao a objeto eh muito aconselhada em projetos de grande porte, principalmente pela redução de codificacao, quando o projeto eh bem estruturado e pela manutencao do mesmo.
Não eh um negocio que se investe hoje e tem um retorno rapido. Eh um retorno demorado, porem depois do investimento, vem sua compensação. Estou utlizando o Enterprise Architect para fazer UML e ele consegue gerar um pouco de codigo, criando pelo menos as classes do delphi, juntamente com os seus tipos de atributos (private, public, protected, etc), mas na hora de fazer a codificação ainda encontro dificuldades. No procedural, jah utilizo herança de forms, repositorios, etc, mas ainda parece que não eh isso o que a orientacao a objeto tem de melhor.Quando desenvolvemos um objeto, tem algumas caracteristicas como: ser atomico, ter alta coesao, ter minima dependencia, transmissao de msg, etc ... efim ... não estou conseguindo desenvolver isso. Acho que isso complica um pouco mais quando tenta-se desenvolver um projeto em POO quando se utiliza n-camadas. Se o client?server tradicional jah é complicado, imagina-se o resto.
Por isso pedi ajuda aos colegas da lista.
Muito Obrigado
GOSTEI 0
