[JAVA] Classes

Yo !

1) a=new B();
2) b=new A();
3) c=(A) new B();


La première compile sans problème (c'est le cas le plus compliqué en fait). Tu peux toujours utiliser une classe mère (ou une interface quand ta classe implémente l'interface) pour manipuler ton objet. Le mécanisme qui est utilisé est un cast implicite.
Le deuxième ne compile pas. Tu ne peux pas manipuler des super classes dans des classes héritées (à moins de faire un downcast : b = (B) new A(); mais c'est assez rare).
Pas de problème pour la 3ème proposition, en fait c'est le même cas que le cas 1), sauf que le cast est explicite (il est écrit alors que dans le cas 1) il n'est pas écrit mais se fait quand même).


a) L'instanciation suivante: C c1=new C(); est-elle juste? Justifier.
b) Soient D et E deux classes telles que D dérive de C et E dérive de D. Peut-on écrire class E extends D, E {}? Justifier votre réponse.


a) Non l'instanciation n'est pas juste. C étant une classe abstraite, elle ne peux pas être instanciée (si un jour tu as la question "qu'est ce qu'une classe abstraite?" tu peux répondre ça. Après tu peux creuser mais c'est la définition même d'une classe abstraite).

b) Non. Outre le fait que E s'étendrait elle-même (je n'ai jamais essayé mais je pense qu'il est impossible de compiler ça :D), en Java une classe ne peut pas étendre plusieurs classes (pas d'héritage multiple). En revanche, une classe peut implémenter plusieurs interfaces sans problème (exemple: public class E implements Interface1, Interface2 extends D {...})

Bonjour,
Je suis au boulot pour l'instant, je n'ai pas le temps. Je t'explique tout ça ce soir.

A tout à l'heure.

Hello,
Un point n'est rien d'autre qu'un cercle ayant un rayon infiniment petit. Ca choquerait peut-être un mathématicien (quoique je suis loin de le penser), mais sûrement pas un ingénieur (un point, physiquement ça n'existe pas).
Je suis moi même ingénieur ;) (et perso ça ne me choque pas).

Je suis d'accord pour la List<String>, mais vu que c'est pour un examen j'imagine qu'il n'est pas perdu parce qu'il a du voir ce genre de trucs en cours, et je voulais surtout montrer qu'on n'est pas obligé de n'utiliser que des types primitifs en attribut.

Le fait qu'il n'y ait pas de fonctions d'accès n'est pas vraiment un problème si la classe servait à quelque chose. Le fait qu'il n'est demandé de n'écrire aucune méthode est assez étrange, ça revient à écrire du code qui ne sert strictement à rien. D'autre part, j'aurais plutôt demandé à écrire l'interface véhicule plutôt qu'une classe, ce serait plus formateur.

De toutes façons en cours tu ne peux pas tout faire. Je pense que l'important est de comprendre les principaux mécanismes objets, comme ça ça peut te servir dans pas mal de langages.
Ensuite, toutes les spécificités du langage, tu les apprends avec la pratique, on ne peut jamais reprocher à un débutant de ne pas connaître toutes les classes de Java :)

Toute classe qui implémente une interface doit forcément fournir une implémentation de chaque méthode définie dans l'interface pour être instanciable. Ce qui n'est pas le cas ici !
En fait ici tu as trois solutions selon moi :

class Vents implements Instrument {
 public void play(){
  System.out.print("Vents.play()");
 } 
 public void adjust(){
  System.out.print("Vents.adjust()");
 }
}

Ensuite aucun problème pour la classe Cuivres qui étend Vents...

La deuxième solution est de déclarer Vents comme classe abstraite : on ne peut pas l'instancier mais on implémente les méthodes de l'interface qu'on veut, et on laisse les autres sans implémentation :

abstract class Vents implements Instrument {
 public void play(){
  System.out.print("Vents.play()");
 } 
 public abstract void adjust();
}

Toujours pas de problème pour la classe Cuivres qui surcharge la méthode play et qui fournit une implémentation à la méthode adjust.
Cependant, Vents étant une classe abstraite elle ne peut pas être instanciée (cependant rien dans l'énoncé n'empêche Vents d'être une classe abstraite).

Enfin, voici la (bonne) solution, c'est-à-dire celle qui a un véritable sens fonctionnel. Les instruments à vent et les instruments à cuivres n'ont pas de lien direct entre eux, la liaison d'héritage (la classe Cuivres qui étend la classe Vents) n'a aucun sens. Par contre, ce sont tout de même des instruments, ils est donc tout à fait possible (et conseillé!) de les faire implémenter l'interface Instruments :

class Vents implements Instrument {
 public void play(){
  System.out.print("Vents.play()");
 } 
 public void adjust(){
  System.out.print("Vents.adjust()");
 }
}

class Cuivres implements Instrument {
 public void play(){
  System.out.print("Cuivres.play()");
 } 
 public void adjust(){
  System.out.print("Cuivres.adjust()");
 }
}

Voilà !

En ce qui concerne la méthode finalize() , une brève recherche sur google m'a éclairé :
La méthode finalize() peut s'occuper de libérer les ressources nécessaires à un objet. Cette méthode est appelée par le ramasse-miettes lorsque l'instance n'est plus nécessaire. Cela peut intervenir bien après la perte de l'objet. Il est préférable de gérer explicitement les ressources par un appel à close(), par exemple lorsqu'un flux n'est plus nécessaire.(http://www.club-java.com/Public/JavaTechno/Fichiers/JAVA/Optimiser.htm)
Je ne connaissais pas cette fonctionnalité (merci donc ;). Mais effectivement elle te permet de libérer les ressources en faisant appel au garbage collector, donc de faire office de destructeur.
C'est une méthode de la classe Object, et comme en Java tous les objets héritent de la classe Object, elle est utilisable par toutes tes instances (tu les castes en Object et tu fais appel à la méthode, ou alors tu surcharges la méthode).

print est une méthode de la classe PrintStream (comme println).
http://java.sun.com/j2se/1.4.2/docs/api/java/io/PrintStream.html
La différence est que println va à la ligne après avoir appelé la méthode toString de ton objet, et pas print.

Bon courage.