• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

Nazgulled

Não consigo interpretar este enunciado!

26 mensagens neste tópico

Boas,

O meu prof de POO já colocou o trabalho online mas eu estou a ter sérias dificuldades em interpretar o enunciado, saber o que fazer e por onde começar. Será que me podem dar uma ajuda?

O problema não é a programação em si, isso é fácil, com mais dúvida menos dúvida é para isso que o P@P existe e os conhecimentos que eu já tenho de C# ajudam um pouco apesar de existir algumas diferenças. Mas o problema é mesmo em interpretar o enunciado e saber por onde começar e organizar aquilo.

Tipo, eu sou muito picuinhas e gosto de fazer as coisas como deve ser e ao pormenor e não estou a conseguir organizar-me depois de ler aquele enunciado. Acho-o extremamente confuso e complicado. Por exemplo, ando a tentar especificar as classes que vou ter e as variáveis que cada classe vai ter mas não estou a conseguir fazê-lo...

Deixo aqui o enunciado:

http://sim.di.uminho.pt/disciplinas/poo/0708/TP_AEROGEST_0708.pdf

Se puderem perder uns minutos a ler e a tentar ajudar-me, agradecia imenso. Esta é uma das cadeiras que eu preciso mesmo de fazer este semestre e queria fazê-la com a melhor nota possível. Para o pessoal da UM que está a fazer este trabalho e se já o começaram e perceberam bem, dêem la uma ajudinha se faz favor...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Assim à primeira vista, esse enunciado é exactamente igual ao que eu resolvi na mesma disciplina há 3 anos atrás :P

A primeira sugestão que te posso dar, é olhares para as palavras a bold, parece-me que te permite identificar a maior parte das classes a criar. Os seus atributos (e possíveis subclasses) estão normalmente logo de seguida.

Depois tenta perceber aquele grafo que aparece no enunciado, pois tem lá as operações que vais poder efectuar a um voo em cada estado.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Sim, até ai já tinha chegado, mas mesmo assim ainda não consegui exactamente perceber quais as classes todas (sem ter uma a mais ou a menos) que vou precisar e que atributos cada uma delas vai ter. Porque tipo, algumas dessas classes vão ter atributos (ou variáveis de instância, como lhe quiserem chamar) que vão ser do tipo de outras classes definidas e estou a ter principal dificuldade nessa parte.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Isso sem ter uma a mais ou a menos é complicado, porque não há a solução. Existem várias, cada uma delas com as suas vantagens e desvantagens, em que as classes podem variar...

Se quiseres posso-te arranjar o trabalho que fiz (que está longe de estar perfeito, mas podes tirar algumas ideias), ou então, apresenta uma lista de classes e atributos, e posso tentar ver se há alguma coisa que falte ou que possas melhorar.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Vais ter de usar o padrão State.

Eu aconselhava-te a fazeres um rascunho com o UML da aplicação. Depois de leres o enunciado todo vais ficar com uma folha de papel.. muito suja :P

Mas depois de passares isso a limpo, ficas com um UML praticamente correcto. Começas a criar as classes (sem funcionalidade).

Finalmente começas a implementar método a método.. : )

Desenvolvimento faseado.. não há nada melhor. Cumprimentos

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Eu aconselhava-te a fazeres um rascunho com o UML da aplicação. Depois de leres o enunciado todo vais ficar com uma folha de papel.. muito suja :P

O meu principal problema (neste momento), está aqui... Não no UML mais propriamente dito, isso é só um tipo de diagramas (já agora, sabem de algum software fixe para o fazer mas que ao mesmo tempo tenha um ambiente moderno e apresentável? for Windows) mas sim em exactamente que classes vou ter e por ai fora, ou seja, fazer o diagrama...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Não sei o que entendes por moderno e agradável, isso é muito abrangente :), mas para UML conheço o Omondo UML que integra com o Eclipse, ou o Netbeans, que tem um módulo de UML.

Um que também usei foi o Visual Paradigm, mas já foi há algum tempo e na altura apenas a versão community era gratuita e era limitada.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Eu tive de usar UML num projecto e tenho dois preferidos:

ArgoUML (Java)

Visio (Office)

Gosto desses dois. O ArgoUML parece muito podre ao inicio.. (e tem montes de problemas com memória) mas valeu o esforço.

Sobre as classes que vais fazer.. Eu não tenho propriamente tempo para ler o enunciado todo, mas vai colocando as dúvidas.

Sei que há mais malta por aqui que tem boas noções de OO e podemos ir-te ajudando. Abraço.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Estou aqui com uma dúvida no trabalho... Para não estar a reescrever, vou deixar aqui uma citação do mail que mandei ao prof e faço-o por duas razões. Gostava de saber a vossa opinião no assunto e o prof não deve responder tão cedo e eu estou a precisar de opiniões neste assunto...

Bom dia,

Numa disciplina como POO seria óbvio o uso de hierarquia na construção das classes para o trabalho prático mas após ler várias vezes o enunciado não consigo perceber em que é que poderei usar hierarquia a como poderei tirar partido de tudo o que hierarquia nos pode oferecer.

Por exemplo, reparei no trabalho de amigos meus e para a classe Aeronave (por exemplo) eles escreveram todo o código necessário para essa classe, ou seja:

- Variáveis de instância

- Métodos de instância

- Métodos que modificam o valor interno das variáveis de instância

- equals, toString e clone

Depois, estão a criar várias classes que herdam da classe Aeronave como AviaoCarga, AviaoPassageiros, Helicopetro e etc... Mas até ao momento ainda não escreveram nada nestas classes, ou seja, o ficheiro de cada uma destas classes está assim:

public class AviaoPassageiros extends Aeronave {

}

Até aqui tudo bem, mas agora é que vem a minha dúvida:

Para além dos construtores que não são herdados e logo nós teremos que os programar (mas não passa de uma linha de código onde com o super() chamamos o construtor da classe Aeronave) que mais variáveis/métodos é que esta subclasse AviaoPassageiros da classe Aeronave vai ter? Já estive aqui a pensar e pensar e não consigo chegar a nenhuma conclusão. Não consigo perceber que partido é que tiro do uso de hierarquia nesta situação.

A única coisa que me passou pela cabeça é que fazendo assim, apenas nos permite, de certa forma, identificar o tipo de aeronave de que estamos a falar. E eu volto a perguntar, é mesmo necessário? Passo a explicar, porque não usar uma enumeração e fazer o seguinte:

(O seguinte exemplo é para simplificar, não está relacionado com o trabalho)

public class Estudante {

    public enum Nota {

        A, B, C, D, E, F, INCOMPLETO

    }

    private String primeiroNome;

    private String ultimoNome;

    private Nota nota;

    public Estudante(String pn, String un, Nota n) {

        this.primeiroNome = pn;

        this.ultimoNome = un;

        this.nota = n;

    }

    (...)

}

public class Programa {

    public static void main(String[] args) {

        Estudante e1 = new Estudante("Pedro", "Sousa", Estudante.Nota.;);

    }

}

Existe algum problema em fazer as coisas desta forma ou terei mesmo que usar hierarquia? Se tenho mesmo de usar hierarquia, gostava de perceber porquê. Porque eu não consigo imaginar que tipo código é que as subclasses vão precisar para além dos construtores e neste caso, não servem para nada para além de identificar o tipo de avião (falando no exemplo real da classe Aeronave) e isso eu posso fazer usando umm enumeração como no exemplo acima.

P.S: Peço desculpa pelo testamento, mas para evitar confusões gosto de explicar os meus problemas ao pormenor.

Cumprimentos,

Ricardo Amaral

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Essa é uma pergunta complicada de responder para quem está deste lado e não sabe o enquadramento da cadeira nem as formas de avaliação.

O que diz a teoria é que, sendo objectos diferentes, são classes diferentes. Em POO estamos a modelar um sistema tomando como exemplo a vida real, os objectos traduzem os relacionamentos da vida real. Uma forma de verificar se uma hierarquia está correcta é até de perguntar se na vida real vamos para o manicómio por dizermos que um objecto é de determinado tipo. Um exemplo um pouco exagerado, se tiveres um carro abaixo da Aeronave, provavelmente não és muito são da cabeça ;)

Assim faz todo o sentido, em objectos do mundo real, que existam essas classes, AviaoCarga, AviaoPassageiros, Helicopetro, que sejam subclasses da Aeronave. Em teoria faz sentido, a nível de POO também faz sentido dado que são objectos diferentes, unidos por um grau de parentesco dado através da classe Aeronave.

Dito isto, se a avaliação da cadeira pretender avaliar o teu POO e não o tipo de programação, se a avaliação se centrar no adquirir dos conhecimentos de análise OO, então os teus colegas estarão mais perto do objectivo. Repara que estão mais perto do teórico. Na pratica, esse problema, dado que não parecem existir qualquer tipo de comportamentos novos que as subclasses possam introduzir, podia muito bem ser resolvido da forma que estás a pensar, usando enumerações, ou até simples constantes.

Talvez comparando com um trabalho da cadeira onde aprendi POO, existiam cerca de 144 classes, para coisas tão simples como InterruptorEsquerdo e InterruptorDireito, sim, para coisas tão idiotas como isto :D, mas a verdade é que o objectivo da cadeira era aprender POO, não era aprender Java  nem optimização nem nada que se pareça, apenas POO, e nesse caso faz todo o sentido teres dois objectos para dois tipos de interruptores. No nosso caso mudava a apenas a imagem mas conceptualmente são dois objectos diferentes.

Portanto, deixaria uma resposta conclusiva para o teu professor porque, embora a tua solução possa estar correcta, pode também estar a afastar-se dos objectivos da cadeira e esses são os que ditam a tua avaliação, como se trata de uma cadeira e não de um projecto diferente, acho que apenas alguém que esteja envolvido pode dar uma resposta que te seja útil.

Mas a tua solução seria muito provavelmente a solução usada noutras situações.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Sim, eu penso que o objectivo desta cadeira é ensinar mesmo POO, até porque é esse o nome da cadeira. A ideia é ensinar o paradigma não os pontos fracos e baixos de Java, penso eu...

No entanto o prof já me respondeu ao mail mas foi muito conciso "polimorfismo e extensibilidade", foi basicamente a resposta dele e disse que depois falávamos melhor na aula (que deve estar a começar, eu estou neste momento na sala, ele não tarda nada deve estar a chegar...).

Estou a ver então então que na prática faço como penso eu era o indicado (ou semelhante), mas na teoria, para aprender conceitos POO, faço com hierarquia de classes, right?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

+/-, eu usei o "provavelmente" ;), há razões para que a teoria seja assim, e o teu prof deu duas, o polimorfismo, que matas completamente com a tua solução, e a extensibilidade que a mesma solução torna complicada. A tua solução é uma solução possível entre tantas outras.

Não quero deixar a impressão que a tua solução é a a escolher, dado que pode não ser a melhor para um determinado problema, mesmo esse problema especifico pode ter outros pontos que invalidem a tua solução. Basicamente não queria que ficasses com a ideia que existe muito a diferença entre a teórica e a prática e que na prática não se programa usando o POO.

Este é mais um problema entre o académico, em que temos de oferecer soluções de acordo com os objectivos da cadeira, e o real, em que são os requisitos da aplicação que ditam as regras.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Agora depois da aula, já deu para perceber o ponto de vista do prof. E resumidamente, depende muito do problema e neste caso especifico, compreendi perfeitamente a ideia de polimorfismo e o partido que posso tirar se fizer as coisas com herança.

Obrigado pela ajuda!

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Embora já tenhas percebido, venho aqui reforçar a ideia de que é "quase" obrigatória criares as sub-classes de Aeronave. Mesmo que para este projecto as sub-classes não acrescentem nada de novo, é mesmo este o objectivo de OO: deixar coisas bem feitas para o futuro.

Sendo assim não é crime nenhum se tiveres classes apenas com:

class Helicopetro extends Aeronave {}

class AviaoCarga extends Aeronave{}

E por aí fora.  ;)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Já agora, no email que enviaste ao teu professor, qual era a tua outra ideia? Teres EstudanteA, EstudanteB, .. a descender de estudante, apenas porque as notas diferiam?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Não, naquele exemplo não teria outra ideia... é um pouco idiota ter EstudanteA, EstudanteB, etc... Entendo isso para o AviãoCarga, Helicopetro e por ai, mas no exemplo que eu dei não teria muita lógica, digo...

O exemplo que eu dei foi só mesmo para usar um exemplo mais simples em vez de fazer um enum { AVIAOCARGA, AVIAOMILITAR, etc... } e depois usa-lo assim... Foi só um exemplo...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Mas neste caso tem lógica estender Aeronave. Já que as propriedades de um avião carga difere de um avião militar, por exemplo número de passageiros, etc.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Mas neste caso tem lógica estender Aeronave. Já que as propriedades de um avião carga difere de um avião militar, por exemplo número de passageiros, etc.

Isso são os valores das propriedades e não as propriedades ;)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Sim eu sei.

Mas se não fosse por herança e sim a usar o enum, tinha-se que estar a definir os valores manualmente, o que não dá muito jeito, para além de complicar evoluções futuras.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Mas o enum iria apenas servir para identificar o tipo de aeronave, nada mais.

A variável que identifica o número máximo da passageiros é igual, seja qual for o tipo de aeronave e eu vou definir os valores manualmente de uma maneira ou de outra, não estou a perceber onde queres chegar e/ou o que queres dizer com isso.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Tipo se usasses só a classe Aeronave com recurso a um enum para distinguir os tipos de aeronaves. No momento de usar tinhas que indicar isso manualmente, isto é,

Aeronave a = new Aeronave();
a.SetTipo(TipoAeronave.AviaoCarga);
a.SetMaxPassageiros(5);
.. etc ..

// ou então teres um construtor para preencher tudo
Aeronave a = new Aeronave(TipoAeronava.AviaoCarga, 5, ..etc..);

Ou seja, sempre que instâncias uma aeronave terias que indicar os parâmetros manualmente.

Ao invés, se usasses herança fazias isso automaticamente.

Aeronave a = new AviaoCarga();

A diferença pode não parecer muita. Mas torna o código mais legível, para além que não ficas preso a evoluções futuras.

Um aparte. Eu li o trabalho muito por alto. Como vi essas propriedades definidas no trabalho, presumi que variassem de aeronave para aeronave. Não tem muita lógica um avião de carga ter o mesmo número de passageiros que um helicóptero.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Já percebi o que queres dizer, é mais ou menos dentro da explicação que o prof me deu :).

Isso do enunciado tens razão no que dizes mas o prof também disse que isso é irrelevante para o trabalho, a ideia não é fazer uma aplicação a sério que possa ser usada na vida real, mas serve apenas para se tentar perceber os conceitos de POO. E nesse caso, não interessa que as propriedades variam de aeronave para aeronave. Ele disse que não estendeu o enunciado com esses pormenores para não ficar muito confuso e que na verdade, não interessam muito para o que é pedido.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
Ele disse que não estendeu o enunciado com esses pormenores para não ficar muito confuso e que na verdade, não interessam muito para o que é pedido.

Isso foi o que ele disse...ontem! Hoje disse que esteve a falar com o Nestor e que vai colocar um anexo com mais cenas pormenorizadas sobre as classes para um gajo implementar, porque anda tudo a queixar-se que a herança/hierarquia de classes não serve para nada! LOL! Esperemos que seja uma piada...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Isso foi o que ele disse na aula ontem que ia criar um anexo mas da maneira que falou deu a entender que não o ia fazer, aliás, ele até disse "mas não o vou fazer"... Se calhar hoje mudou de ideias lol.

Mas por um lado eu acho bem... Ajuda melhor a entender o conceito de POO. Para quem não percebe nada de POO, ver um enunciado daqueles não ajuda muito a fazer uma classe Aeronave e depois fazer várias subclasses em que não muda praticamente nada.

Agora que já percebi, não valia a pena o anexo lol, mas acho bem :)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

[...] porque anda tudo a queixar-se que a herança/hierarquia de classes não serve para nada!

Discordo. Mesmo sem mais pormenores, a utilização de várias classes, facilita a extensão da aplicação com mais tipos de aeronaves.

Esta é do meu ponto de vista a principal razão para o fazer, e por isso não me parece que sejam necessários mais pormenores.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora