Fórum Cadastro Orientado a objeto #266167

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

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...

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.

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