Boa tarde,
estou com um problema em um mini-projeto e gostaria que se possível, me ajudassem a alterar meu projeto para que fique orientado a objetos.
Segue o link do projeto:
http://projetos.edugraf.ufsc.br/2013/1/convidado/POO2/projetos/PabloMontezano/V0.121/
na pasta recursos está a imagem resumida do modelo UML
na pasta src/modelo estão as classes, src/testes estão os testes feitos usando JUnit.
Qualquer informação que puder me orientar será de grande ajuda.
Estude padrões em java, como por exemplo os métodos getters e setters.
O projeto está orientado a objeto a partir do momento em que se utiliza uma classe, resumindo, desde quando começa.
Não entendi o problema no projeto, poderia ser mais claro?
[quote=lucaslzl]Estude padrões em java, como por exemplo os métodos getters e setters.
O projeto está orientado a objeto a partir do momento em que se utiliza uma classe, resumindo, desde quando começa.
Não entendi o problema no projeto, poderia ser mais claro?[/quote]
No teu ponto de vista isto
public class Classe{
public static void main(String[] args){
System.out.println("Orientação a objetos não é apenas usar classes");
}
}Está orientado a objetos?
Engraçado, eu discordo.
Orientação a Objetos é um paradigma que envolve alguns conceitos bem importantes. Lógico que nem todos precisam estar em uso, mas, você deve, obrigatoriamente, ter objetos e não apenas classes.
Objetos trocam mensagens, logo, uma instância de um objeto deve possuir métodos, que são a origem e o destino das mensagens.
Cada método (origem/destino de uma mensagem) tem a propriedade de alterar valores (definir ou obter) em um ou mais atributos da instância de objeto em questão.
Notou a diferença dos conceitos?
Segundo o meu orientador, o programa não contêm classes abstratas, logo (segundo ele) não está orientado a objetos. Uma outra falha que o orientador apontou, foi que não existem heranças entre as classes. Eu não consegui enxergar onde possa usar interfaces ou heranças usando este tema de projeto.
Quanto aos getters e setters, foi pedido que fosse evitado de ser usado.
[quote=montez85]Segundo o meu orientador, o programa não contêm classes abstratas, logo (segundo ele) não está orientado a objetos. Uma outra falha que o orientador apontou, foi que não existem heranças entre as classes. Eu não consegui enxergar onde possa usar interfaces ou heranças usando este tema de projeto.
Quanto aos getters e setters, foi pedido que fosse evitado de ser usado.[/quote]
Primeiro, o fato de existir ou não classes abstratas não significa que você não use OO.
Segundo, herança é um dos conceitos de OO que você pode ou não usar (de preferência, não use, opte por composição/agregação).
Terceiro, getters e setters você vai utilizar se houver necessidade. E, normalmente, há. Você cria atributos privados, para trabalhar com encapsulamento. Em algum momento precisará acessar os valores contidos nas variáveis ou definir valores à algum atributo.
[quote=montez85]Segundo o meu orientador, o programa não contêm classes abstratas, logo (segundo ele) não está orientado a objetos. Uma outra falha que o orientador apontou, foi que não existem heranças entre as classes. Eu não consegui enxergar onde possa usar interfaces ou heranças usando este tema de projeto.
Quanto aos getters e setters, foi pedido que fosse evitado de ser usado.[/quote]
Como? Um programa não precisa ter classes abstratas para ser orientado a objetos.
Mas se vc utilizar classes abstratas, obrigatoriamente terá que utilizar herança para utiliza-la.
Não vi seu fonte todo, mas acho que seu orientador quer que vc utilize a classe abstrata pra ver se vc domina estes conceitos.
[quote=lucaslzl]Estude padrões em java, como por exemplo os métodos getters e setters.
O projeto está orientado a objeto a partir do momento em que se utiliza uma classe, resumindo, desde quando começa.[/quote]
Cara getters e setters são convenções e não um padrão de projeto.
E um projeto sem as características e benefícios da orientação a objetos pode muito bem ser considerado estruturado. Não basta programar com a linguagem Java, usar classes e pronto. Tem que saber usar conceitos como abstração, encapsulamento, herança, interface, polimorfismo…
Entendi a idéia. Percebo que o conceito que eu tinha de OO não está errado. O que eu possa precisar é escolher um outro tema, aonde seja mais clara a utilização de herança, abstrações etc.
drsmachado:
A classe ao ser compilada se torna um objeto, a classe é um molde, e o objeto é a “cópia” dela sendo utilizada.
O método main é um método.
Não digo que utiliza muitos conceitos de orientação a objetos, mas mesmo assim é orientado a objeto.
fredericomaia10:
Eu não disse que os conceitos não são importantes (polimorfismo, interfaces, etc), eu dei o exemplo dos métodos getters e setters para seguir padrão, e sim, padrão é importante pois o seu código pode ser lido por outros programadores anos depois. Se ele não tem segurança para saber se o projeto é orientado a objeto ou não imagina quanta teoria ele tem, ele tem que começar do básico, como por exemplo, é ensinado no livro do Deitel : Java Como Programar.
Olhando o projeto, ele tem um código bem construído, mas acho ele pouco funcional, ou pelo menos não segue o que eu esperaria de um Roteador ou do DHCP. Essas classes estão mais servindo como banco de dados que como unidades lógicas de um programa.
Por exemplo, no caso so DHCP, parece que é o cliente que tem que pesquisar quais IPs estão disponíveis, remover um IP, perguntar sem tem espaço o suficiente. Eu acho que um DHCP deveria funcionar só com o gerarIP, que dá um IP para o cliente, ou nada quando não couber mais clientes. Depois de um tempo se o cliente não pedir para renovar a assinatura dele desse IP, o servidor remove esse IP da lista dos alocados automaticamente. Outra lógica é quando o cliente pedir para gerar um IP, que o DHCP cheque na lista interna se existe um cadastro desse MAC que foi mandado para ele, e dê o IP associado à esse MAC.
E terceiro, se quiser demonstrar herança e interfaces, crie um IPAltaPrioridade e IPBaixaPrioridade, onde ambos implementem a interface de IP.
Quando o IPAltaPrioridade for passado para o Roteador, ele tem prioridade na fila de mensagens. Alias dentro do Roteador você pode implementar ele como um aparelho que mande e receba mensagens, com uma fila interna com prioridades. Ele tb pode ter um um método conectar(porta, EquipamentoDeRede, onde Roteador implementa EquipamentoDeRede), e internamente uma lista de rotas, onde fala que mensagens para a rota X(rota é uma subrede de IP) vão para a a porta 14, e disso um roteador manda a mensagem para outro.
Espero que você já tenha algum conhecimento de redes para saber o que são rotas, e o que DHCP e Roteadores fazem na vida real, para fazer um mock disso.
T+
[quote=lucaslzl]drsmachado:
A classe ao ser compilada se torna um objeto, a classe é um molde, e o objeto é a “cópia” dela sendo utilizada.
O método main é um método.
Não digo que utiliza muitos conceitos de orientação a objetos, mas mesmo assim é orientado a objeto.
fredericomaia10:
Eu não disse que os conceitos não são importantes (polimorfismo, interfaces, etc), eu dei o exemplo dos métodos getters e setters para seguir padrão, e sim, padrão é importante pois o seu código pode ser lido por outros programadores anos depois. Se ele não tem segurança para saber se o projeto é orientado a objeto ou não imagina quanta teoria ele tem, ele tem que começar do básico, como por exemplo, é ensinado no livro do Deitel : Java Como Programar.[/quote]
Primeiro, camarada, não se compila uma classe. Compila-se o arquivo com extensão .java o que irá criar uma ou mais .class
Segundo, uma classe é uma representação de um objeto, a partir da qual, as instâncias de objetos serão obtidas. Um objeto não é uma cópia de uma classe, caso fosse, não haveria sentido métodos e atributos estáticos (que pertencem à classe e não ao objeto).
Uma classe como a que mostrei acima nunca pode ser dita que está empregando OO. Ela é como o método main do C. É puramente estruturada.