Na verdade não é nada disso. Deve-se codificar para uma interface e não para uma CLASSE. Isso não tem nada haver com tabela e também não tem a intenção de fazer com que a classe que implementa a interface seja forçada a implementar algo.
A idéia da implementação de interfaces é desacoplar a implementação de uma classe, de modo que ela se torne genérica. Isso é codificar para um interface e não para uma classe. Um exemplo é uma impressora fiscal. Existem diversas impressoras fiscais no mercado com diferentes funcionamentos, porém todas tem como principal funcionalide a impressão de cupons fiscais. O acesso a essa funcionalidade é feita de diversas formas por diferentes impressoras. Se eu quiser usar isso no meu sistema, terei que utilizar uma série de IFs para realizar a impressão de um cupom.
Porém eu posso criar uma interface chamada ImpressoraFiscal com um método imprimirCupom(), por exemplo. Em todos os lugares que seja necessário imprimir um cupom, utiliza-se a interface. Isso desacopla a chamada ao metodo imprimirCupom da sua implementação. Todas as classes que queiram imprimir o cupom utilizam a interface e cada impressora implementa sua forma de impressão do cupom. Se eu quiser adicionar uma nova impressora isso se torna fácil, pois não é necessário alterar o código em todos os lugares que necessitam realizar a impressão.
Na verdade não é nada disso. Deve-se codificar para uma interface e não para uma CLASSE. Isso não tem nada haver com tabela e também não tem a intenção de fazer com que a classe que implementa a interface seja forçada a implementar algo.
A idéia da implementação de interfaces é desacoplar a a implementação de uma classe, de modo que ela se torne genérica. Isso é codificar para um interface e não para uma classe. Um exemplo é uma impressora fiscal. Existem diversas impressoras fiscais no mercado com diferentes funcionamentos, porém todas tem como principal funcionalide a impressão de cupons fiscais. O acesso a essa funcionalidade é feita de diversas formas por diferentes impressoras. Se eu quiser usar isso no meu sistema, ira ter que utilizar uma série de IFs para realizar a impressão de um cupom.
Porém eu posso criar uma interface chamada ImpressoraFiscal com um método imprimirCupom(), por exemplo. Em todos os lugares que seja necessário imprimir um cupom, utiliza-se a interface. Isso desacopla a chamada ao cupom da sua implementação. Todas as classes que queiram imprimir o cupom utilizam a interface e cada impressora implementa sua forma de impressão do cupom. Se eu quiser adicionar uma nova impressora isso se torna fácil, pois não é necessário alterar o código em todos os lugares que necessitam imprimir o código.[/quote]
[quote=Slow17]
Entendi,realmente o codigo fica muito dependente do banco de dados da maneira que eu imaginava um sistema,mas então o ideal seria oque? pensar em quais diagramas primeiro? no diagrama de classe e de caso de usos? qual seria a ordem de planejamento do projeto?[/quote]
Como disse a primeira coisa é entender o que deve-se implementar. Isso é fundamental. Se você vai implementar um modelo de um carro para simulação de consumo de combustivel, deve saber como um carro funciona, para que serve cada peça. Não adianta só saber que depois o carro vai ser usado para transportar pessoas. Agora se você vai implementar um sistema para um radio taxi, o carro vai ter outro papel no modelo, e caracteristicas que interessam a esse papel, nesse cenário. Vai ser necessário entender como funciona uma radio taxi para implementar o sistema.
Depois pode-se criar um modelo de classes, mas um modelo enxuto para organizar as idéias. Esse modelo não tem campos e praticamente não tem métodos. O foco dele deve estar no relacionamento com outras classes. O modelo é um rascunho do sistema e só isso.
Ai começa a implementação, nesse momento vão surgir novas idéias, e modelo que foi feito será alterado, talvez o resultado final seja totalmente diferente do modelo incial esboçado. Isso é muito importante, pois o sistema não deve ser dependente de um modelo previamente executado.
voltei aqui não estou mais entendendo é quse nada, mais obrigado ai galera pelomenos fiz um post que não so ajudou a min como está ajudando outras pessoas.
Trabalhar em grupo ou com uma pessoa mais experiência é o melhor caminho. Se ofereça pra ajudar em algum freelance. E nesse processo esteja tranquilo para receber criticas e evoluir com isso.
dsntnow, o que o pessoal está tentando te dizer é que há técnicas para se “modelar” um software. Provavelmente não é possível “entender” tudo de cara, isso deve ser estudado.
Procure estudar sobre:
Análise e projeto orientado a objetos
Padrões de projeto (design patterns)
Desenvolvimento dirigido por testes (TDD - test driven development)
Tudo isso vai te ajudar a “pensar” melhor o software, mas te aviso que terá um tempo de aprendizado até vc dominar tudo.
[quote] javaflex
Trabalhar em grupo ou com uma pessoa mais experiência é o melhor caminho. Se ofereça pra ajudar em algum freelance. E nesse processo esteja tranquilo para receber criticas e evoluir com isso.[/quote]
vou procurar alguem…
obrigado pelas dicas agora estou vendo mais claro o que devo estudar.
Lembro que quando eu fiz o primeiro cursinho de Java, também tinha “sangue no olho” e saía codificando que nem um macaco doido!
Outro dia olhava praquilo que fiz e pensava “que porcaria eu fiz aqui?!?”
É normal, principalmente no começo. A gente fica animado com as possibilidades de criação que a linguagem proporciona, temos vontade de fazer tudo o que vem na cabeça, é normal acontecer isso…
O que você precisa agora é estudar um pouco de projetos, ver o que rola antes do serviço chegar na mão do programador.
Comparando meu comportamento de 2 anos atrás pra hoje eu vejo o quanto mudei. Em exercícios da faculdade não é difícil passar mais de meia hora planejando, montando estrutura de classes em UML, anotando tudo, para só depois codificar.
Você vai notar que se passa mais tempo projetando a estrutura e regras de negócio do que codificando. Codificar é só passar o que tá no papel pro computador. E logicamente, se você tem um bom planejamento e principalmente divisão correta de responsabilidades entre as classes, vai ter um código tinindo de lindo!
Desenvolver é bem mais que passar o dia inteiro codificando na IDE, tem muito planejamento e estudo antes!
