Bom, vou fazer uma pergunta meio painelzão de jipe, simprona.
Fiz um sisteminha de cadastros (estava com pressa) onde ao invés deu criar os objetos em si, apenas baixei as colunas das tabelas como se fossem atributos de meus objetos…
Por exemplo: meu objeto é um projeto, dae os atributos seriam data de inicio, fim, pontos criticos, nome etc. Lógico que na tabela projetos tenho estas colunas. Dai joguei tudo isso pra vetores e fui trabalhando ao longo do programa.
Acho que existem duas coisas erradas nisso que fiz: o conceito, porque não acho que isso seja poo, a não ser que eu entenda que meu objeto é a tabela, por exemplo. Outra coisa, trabalho com vetores, o que é extremamente desaconselhável.
Mas cheguei a um bom resultado, porque o sistema ficou com um custo de manutenção baixíssimo, se eu precisa adicionar algo, adiciono um campo na tabela do banco.
Outra coisa, se eu fosse trabalhar com arrayList, visualmente ficaria impossível de ler o código, porque mtos arraylists precisariam ser bidimensionais.
É correto esse padrão de projeto? isso é um padrão?
valeu ae.
Isso é praticamente um sistema estruturado. E para certas aplicações de cadastro, realmente, é muito mais fácil usar esse paradigma.
Não é à toa que muitos se sentem mais improdutivos no Java do que eram no Clipper, lá em 1986…
Mas claro, esse paradigma também tem suas limitações. Especialmente quando o negócio em si tem estruturas que seriam bem modeladas com uso de polimorfismo.
Ser POO não é a questão; isso é um atributo importante, mas etéreo. O que você deve se perguntar é: é um sistema legível, é de fácil manutenção, é difícil “se enganar” ao escrever extensões no código? Minha opinião: do jeito que você escreveu, é não pra todas as perguntas.
O erro não está em você usar arrays, ou usar uma Collection. O erro é você usar uma estratégia de implementação de acesso persistente (armazenar os dados do banco numa estrutura simplória), e não isolá-lo dentro de um DAO, por exemplo. Muito provavelmente, as telas de apresentação estão dependendo desses arrays. Isso torna seu sistema engessado demais, pois quando você se arrepender dos arrays, só um tiro de espingarda resolve.
Você está organizando a lógica do domínio de sua aplicação seguindo a abordagem mais simpista possível.
Sua aplicacao não possui um modelo de dominio orientado a objetos e independente do seu modelo relacional.
Ao que parece sequer possui objetos que espelham as entidades de negócio do modelo relacional (Row Data Gateway e Table Data Gateway).
Trabalhar puramente com ResultSet e RowSet do JDBC com certeza é muito menos extensível do que você está imaginando, contudo para uma pequena aplicação pode ser aceitável.
ViniGodoy, eu so cabeça dura… hehehehee. O pior é a história disso. Criei duas classes, uma que gera os formulários e outra que controla o fluxo deles e instancia eles. Acontece que quando o programa precisou de adaptações, extends na classe que cria os formulários, e ela virou praticamente uma abstrata… pelo menos no sentido funcional. Toda a parte gerencial e de relatorios, faço em php, então as limitações desse padrão java não vai matar, acho.
Leonardo, realmente muitas partes do código estão prolixas. Mas estou reescrevendo, inclusive acho que vou trocar esses vetores por hashmaps, que vou popular com classes intermediárias, objetos mesmo… mas essa é outra questão. O mais importante é que estou revisando justamente a estratégia, e heehehehehe, a galera tá ajudando pra caramba, sempre tenho umas aulas aqui, valeu memo.
Franco, não sou entendido de programação a objeto, programei mto tempo em vb. Quando começei a ler sobre poo, decidi fazer este teste, ao invés de criar objetos em si, concretos, criar objetos flexíveis, criados dinamicamente pelo programa. O que ele faz é pegar os atributos do objeto no banco, e jogar pra classe. Minhas classes tem meta-objetos. Elas baixam os dados, os atributos das classes, quando alguem bem entende modifica os atributos das classes através do banco… carrega inclusive as classes em si, serializadas, de qualquer ponto da rede.
[quote=FrancoC][quote=zerokelvin]
… ao invés de criar objetos em si, concretos, criar objetos flexíveis, criados dinamicamente pelo programa. O que ele faz é pegar os atributos do objeto no banco, e jogar pra classe. Minhas classes tem meta-objetos. Elas baixam os dados, os atributos das classes, quando alguem bem entende modifica os atributos das classes através do banco… carrega inclusive as classes em si, serializadas, de qualquer ponto da rede.
[/quote]
Suas classes tem meta-objetos? :?: :shock: :!:
Acho que além de não conhece Orientacao a Objetos você também tem dificuldade de se fazer compreensível…[/quote]
orra…
Como sei muito de oo, postei este tópico no java básico, e vc respondeu ele no java básico, acho menos grave minha incapacidade de me expressar que a sua de compreender.
" Java Básico
Para quem está começando em Java. Dúvidas em relação a compilação, instalação, sintaxe, Orientação a Objetos (OO), problemas com lógica & afins. "
O Guj é bom pra caramba, vejo humildade e cnhecimento em mtos caras. Mas tem uns nego que são mto minino da vovó cara, acho que os caras num pegam muié, a tensão fica na última, dae são arrogantes com os caras que estão aprendendo. Obrigado pela sua primeira resposta, mas essa ultima foi desnecessária.
Peço desculpas se minha resposta pareceu grosseira. A intenção era apenas lhe chamar a atenção de que a clareza é o único pré-requisito para se participar de um fórum. Assim quando procuro transmitir o pouco do conhecimento que tenho perco até mais tempo do que desejaria com a intenção de ser o minimo didatico possivel. Da mesma forma a pessoa com dúvidas e questionamentos também deve ter essa preocupação: ser objetiva e clara.