Sou novo no fórum estou aprendendo java agora , na cadeira de orientação a objetos na faculdade ! e estou com algumas dúvidas ,talvez porque ainda eu esteje pensando com o paradigma imperativo e não em OO ainda. Espero que possam me ajudar!
Tenho que implementar um programa que faça a simulação de um máquina hipotética criada para fins didaticos (para ARquitetura de computadores e Tecnicas digitais etc …).
A Dúvida é: Criei Classes Que são o PC( Program counter ), Acumulador(ou a memoria “cache”… não é extamente isso),Memoria( Dados e Codigo Juntos, da maquina implementada),ULA( Unidade logica e aritmetica) e a Unidade de Controle. Todos declarados com static pois são objetos unicos.
Onde devo chamar os métodos construtores deles ? Teria como o método construtor da unidade de Controle conter os outros métodos construtores ?? OU devo criar os Objetos na minha função main mesmo ??
Não sei se fui claro , mas espero que sim ! Obrigado pela atençção!
Métodos estáticos estão associados á classe, e não a objetos da classe. Então se seus métodos são estáticos, você não precisa criar objetos, e consequentemente não precisa usar construtores.
Sugiro que você não use métodos estáticos. E se você vai ter apenas um objeto de cada tipo, não tem problema: instancie apenas um objeto! É preferível fazer isso do que usar todos os métodos estáticos.
Neste seu caso, acredito que seja interessante você instanciar todos os objetos num lugar único, que pode ser sim seu método main() ou outro método (que pode até ser de uma classe específica) que seja responsável por isso!
Não vejo problema algum em você utilizar classes somente com métodos estáticos. É importante separar o que é uma Classe no Paradigma da Orientação a Objetos e o que representa esse bloco construtor para a linguagem Java.
Você realmente necessita criar um Modelo de Domíno rico para teu simulador? Haverá uma rede de objetos interconectados, herança, polimorfismo e padrões de projeto?
Se voce acha que sim, construa teus POJOs baseando-se nessas entidades. De qualquer forma considero um desperdicio de tempo. Estás pecando por excesso de granularidade.
Para este exercicio de construir teu simulador de máquina recomendo que faça tudo em uma única classe. No máximo separe, no caso de houver, a Interface de Usuário do simulador.
Uma decisão importante seria se tua máquina irá manipular numeros decimais ou binários? O Java tem suporte a operadores Bit-a-bit.
[quote] Você realmente necessita criar um Modelo de Domíno rico para teu simulador? Haverá uma rede de objetos interconectados, herança, polimorfismo e padrões de projeto?
Se voce acha que sim, construa teus POJOs baseando-se nessas entidades. De qualquer forma considero um desperdicio de tempo. Estás pecando por excesso de granularidade.
[/quote]
Necessito sim pois como e o trabalho semestral da cadeira OO o Prof exige que seja assim.Justamente para evidênciar o conhecimento de OO ( ou o não conhecimento …) mas obrigado pelas dicas !
[quote=FrancoC]Você realmente necessita criar um Modelo de Domíno rico para teu simulador? Haverá uma rede de objetos interconectados, herança, polimorfismo e padrões de projeto?
Se voce acha que sim, construa teus POJOs baseando-se nessas entidades. De qualquer forma considero um desperdicio de tempo. Estás pecando por excesso de granularidade.
[/quote]
Já o meu pensamento é o oposto Não consigo enxergar um programa orientado a objetos sem objetos. E para que existam objetos, é necessário que haja um modelo de domínio, sempre. E como neste caso a proposta é modelar uma máquina, fica evidente a presença de uma rede de objetos interconectados.
Orientação a objetos é um conceito. Posso programar de forma imperativa em Java? Claro que pode! Basta você criar métodos estáticos em uma classe e chamá-los. Por isso é preciso tomar cuidado com eles: trazem à tona alguns problemas da programação imperativa que a orientação a objetos visa resolver.
Claro que para um exemplo pequeno é talvez não seja necessária a criação de toda uma estrutura de classes. Mas como o exemplo é para uma disciplina de OO, a criação de todo este modelo é justificável. Na prática, é preciso tomar sim cuidado com a granularidade, concordo plenamente. Não adianta nada entupirmos o projeto de classes que talvez jamais serão úteis, já que isso só vai poluir seu código. É por isso que existe a técnica de refactoring Mas montar um modelo consistente com a realidade nunca vai ser perda de tempo se você quiser escrever um código fácil de manter e de estender com o passar do tempo.
Boa parte de todo o software no mundo foi implementado, e continua sendo, com tecnologias procedurais, entre elas o S.O. que você está utilizando, e provavelmente o navegador também. Na verdade, no campo da programação estritamente falando, não há nenhum grande problema que a Orientacao Objetos se propôs a resolver. As classes de hoje, não sao nada mais do que os Tipos de Dados Abstratos do passado. A Orientaçao a Objetos surgiu mais como um novo paradigma para concepção e modelagem de projetos com a codificacao retratando o mais fielmente possível tal projeto.
Não sei de onde tiram essa idéia que a abordagem procedural é sempre falha. Pra mim isso se chama falta de experiencia e o minmo de pensamento critico nas nossas universidades.
Não consigo enxergar um programa orientado a objetos sem objetos. E para que existam objetos, é necessário que haja um modelo de domínio, sempre. E como neste caso a proposta é modelar uma máquina, fica evidente a presença de uma rede de objetos interconectados.
Mas montar um modelo consistente com a realidade nunca vai ser perda de tempo se você quiser escrever um código fácil de manter e de estender com o passar do tempo.