Não consigo interpretar este enunciado!

[Guest id194]

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...

[Rui Carlos]

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

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.

[Guest id194]

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.

[Rui Carlos]

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.

[MX+]

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 😛

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

[Guest id194]

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 😛

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...

[Knitter]

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.

[MX+]

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.

[Guest id194]

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

[Knitter]

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 😄 , 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.

[Guest id194]

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?

[Knitter]

+/-, 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.

[Guest id194]

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!

[MX+]

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.  😉

[MX+]

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?

[Guest id194]

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...

[Betovsky]

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.

[Knitter]

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 😉

[Betovsky]

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.

[Guest id194]

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.