Discussion :

[LinuxUser]

Bonjour, je revise pour un partiel de java en répondant aux questions d'un QCM et je voudrais des précisions sur certaines questions.
Par exemple :

Une classe abstraite peut :
A : etre referencee
B : etre instanciee
C : avoir des constantes
D: avoir des champs
E: avoir des méthodes non abstraites
F : se deriver
G : etre implementée
H : aucune des réponse precedentes

Donc là j'ai mis D, E, F.
Et qu'est ce qu'il entendent par referencé?
Merci.

[adiGuba]

Salut,

Et qu'est ce qu'il entendent par referencé?

Je pense qu'ils veulent dire qu'on peut créer une référence sur un type abstrait, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
MonTypeAbstrait reference1 = null;
MonTypeAbstrait reference1 = new MonTypeQuiEtendMonTypeAbstrait();

Au passage, les classes abstraites peuvent très bien avoir des constantes

a++

[Rayndell]

Etre référencée, c'est-à-dire que tu peux utiliser des objets de type ClasseAbstraite mais sans les instancier. Exemple :

Tu as une classe abstraite A. Deux classes B et C dérivent de ta classe A. Dans un programme, tu sais que tu dois recevoir des objets de type A (c'est-à-dire dérivant de A) mais tu ne sais pas si ce sont des objets de type B ou C. Tu peux donc référencer ces objets que tu reçois en les déclarant comme de type A.

Il me semble également qu'une classe abstraite peut avoir des constantes, en tout cas statiques.

[EDIT] Eh merde, grillé...

[LinuxUser]

Merci, par contre si il s'agit d'une interface je pense qu'elle peut :
- etre referencée
-etre instanciée
-avoir des constantes
-se deriver


En gros A B C F, enfin je crois.

[adiGuba]

Pas tout à fait : une interface ne peut pas être instanciée, elle ne peut pas avoir de champs ni de méthode non-abstraite...


Pour une interface, les réponses sont : A C F G :

• A : etre referencee
• C : avoir des constantes
• F : se deriver
• G : etre implementée

a++

[LinuxUser]

J'ai cru avoir lu dans un cours que si on avait une interfance A, on pouvait déclarer un objet A a par exemple.
Pour ce qui est de "peut être impléméntée" , je pensait que ça voulait dire qu'on pouvait coder les méthodes de l'interface dans l'interface, en fait si j'ai bien compris ça veut dire que la classe qui hérite de l'intérface peut l'implémenter d'où le mot clef

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

implements

[Rayndell]

Une classe qui implémente une interface (mot-clé implements après le nom de la classe en effet) peut être déclarée comme étant du type de l'interface mais doit également implémenter toutes ses méthodes.

[LinuxUser]

Si A est une interface, on peut donc définir des variables de type A(donc instancier A si j'ai bien compris), quitte à référencer cette objet à une classe implémentant l'interface A. C'est bien ça?

[Rayndell]

C'est le contraire. Tu peux déclarer un objet de type A mais pas l'instancier : Si A est une interface et si B implémente cette interface, alors tu peux faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
A truc = new B();
// Mais surtout pas A truc = new A(), de toutes façons
// les interfaces ne possèdent pas de constructeur

[LinuxUser]

A ok, je pensais que le fait d'écrire A truc c'était déjà une instance.
Donc si je résume bien, une interface peut :
-être réferencée
-avoir des constantes
-être implémentée

Mais ne peut pas :
-être instancié
-avoir des champs (sauf constantes)
-avoir des méthodes non abstraites
- se dériver


Enfin dériver je suis pas trop sûr, car quand une interface implémente une autre on met extends au lieu de implémente, donc pour "se dériver" je ne sais pas trop.

[Rayndell]

Une interface peut être dérivée : Si A est une interface, on peut très bien faire une interface B qui hérite de A, éventuellement en surchargeant des méthodes existantes ou en en ajoutant. En revanche je ne crois pas qu'une interface puisse avoir des constantes. Cela demande réflexion.

[Benouze]

Bonjour,

Enfin dériver je suis pas trop sûr, car quand une interface implémente une autre on met extends au lieu de implémente, donc pour "se dériver" je ne sais pas trop.

Une interface ne peut pas implémenter quoi que ce soit, ce sont les interfaces qui peuvent être implémentées par des classes donc au même titre qu'une classe peut dériver (extends) d'une autre classe, une interface peut dériver (extends) d'une autre interface (par exemple l'interface java.util.List dérive de l'interface java.util.Collection)
Et on peut effectivement mettre des constantes dans une interface (cf. l'interface javax.swing.SwingConstants qui ne contient que ça par exemple).

[LinuxUser]

Par contre j'ai une question au sujet des constructeurs.
Une classe peut avoir :
A : un constructeur
B : plusieurs constructeurs
C : un constructeur avec l'attribut private et un constructeur avec l'attribut public
D : un constructeur qui apelle un autre constructeur de la même classe
E : un constructeur qui apelle un autre constructeur de la classe ascendante
F :un constructeur qui apelle un autre constructeur de la classe descendante

A : oui
B : je pense mais je ne suis pas sûr, je pense qu'on peut définir le constructeur de base et d'autres constructeurs avec d'autres attributs, et que lorsqu'on instancie l'objet le bon constructeur sera appellé en fonction des attributs mis en argument.
C : je ne pense pas qu'un constructeur puisse avoir l'attribut private
D : non
E : oui
F : non

[adiGuba]

En revanche je ne crois pas qu'une interface puisse avoir des constantes. Cela demande réflexion.

Une interface peut très bien avoir des constantes. La preuve avec l'interface SwingConstants

B : je pense mais je ne suis pas sûr, je pense qu'on peut définir le constructeur de base et d'autres constructeurs avec d'autres attributs, et que lorsqu'on instancie l'objet le bon constructeur sera appellé en fonction des attributs mis en argument.

Oui une classe peut bien avoir plusieurs constructeur, à conditions qu'ils aient des paramètres différents

C : je ne pense pas qu'un constructeur puisse avoir l'attribut private

Un constructeur peut avoir n'importe quel attribut de visibilité.
Le constructeur privée est notamment utilisé dans le design pattern du singleton

[QUOTE=juve1897]D : non[/code]
On peut très bien appelé un autre constructeur de la même classe avec this(). Tout comme super() cela doit être la première instruction du constructeur. Cela permet par exemple de simuler des paramètres optionnel en écrivant des constructeurs qui se contente d'en appeler un autre plus complet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
class MyClass {
 
	private final String name;
	private final int id;
 
	/**
         * Constructeur avec tous les paramètres :
         */
	public MyClass(String name, int id) {
		this.name = name;
		this.id = id;
	}
 
	/**
         * Constructeur avec id automatique
         */
	public MyClass(String name) {
		this(name, 0); // on force l'ID à zéro
	}
 
	/**
         * Constructeur avec nom et id automatique
         */
	public MyClass() {
		this("default", 0); // on force le nom et l'ID 
	}
}

(Note : on peut également faire l'inverse : le constructeur le plus complet appelle les constructeurs moins complet).


Pour le reste c'est bon

a++

[LinuxUser]

Toujours en rapport avec les constructeurs,

La construction d'une classe dérivée est possible avec :

A : une classe de base sans constructeur et une classe dérivée sans constructeur
B : une classe de base sans constructeur et une classe dérivée avec constructeur
C : une classe de base avec constructeur et une classe dérivée sans constructeur
D : une classe de base avec constructeur et une classe dérivée avec constructeur

A : ok pas de problème
B : idem
C : la je pense que oui, mais je suis pas sûr, je pense que le constructeur vide de la sous classe appelle le constructeur de la classe mère
D : pas de problème

[Rayndell]

Euh... Tu vas nous balancer toutes les questions de ton QCM ???

Sinon je pense que toutes les réponses sont bonnes.

[je®ome]

Vive Michel !!!!
Ne t'inquiète pas, il n'y a pas moyen d'avoir moins que 0.

[adiGuba]

Toujours en rapport avec les constructeurs,

La construction d'une classe dérivée est possible avec :

A : une classe de base sans constructeur et une classe dérivée sans constructeur
B : une classe de base sans constructeur et une classe dérivée avec constructeur
C : une classe de base avec constructeur et une classe dérivée sans constructeur
D : une classe de base avec constructeur et une classe dérivée avec constructeur

En fait ce n'est pas si simple, car il faut prendre en compte deux éléments :

• "une classe de base sans constructeur" ne peut pas exister, car si on n'écrit aucun constructeur, c'est le compilateur qui en génèrera un automatiquement.
• Un constructeur appelle toujours un des constructeur de la classe parent avec super(). Si ce n'est pas fait explicitement par le developpeur ce sera fait implicitement par le compilateur.

Ainsi cette classe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
class Test {
 
}

est équivalente à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
class Test {
	public Test() {
	}
}

et est équivalente à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class Test {
	public Test() {
		super();
	}
}

A : ok pas de problème
B : idem

C'est vrai, mais en fait les classes ont un constructeur vide sans paramètres

C : la je pense que oui, mais je suis pas sûr, je pense que le constructeur vide de la sous classe appelle le constructeur de la classe mère

En fait cela dépend du constructeur de la classe de base.
Puisque la classe dérivé ne possède pas de constructeur, le compilateur génère un constructeur automatique de la forme suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public Classe() {
    super();
}

Donc cela ne peut marcher que si la classe de base possède un constructeur sans paramètre et ne remontant pas d'exception...

D : pas de problème

Encore une fois cela dépend des constructeurs des deux classes et des appels implicites ou non aux constructeurs parents.

Un exemple où cela ne pourrait pas marcher : le constructeur de la classe de base n'est pas visible (private par exemple). Ou alors la classe de base possède seulement un constructeur avec paramètre et la classe fille ne fait pas d'appel explicite à ce constructeur

a++

[LinuxUser]

Ok merci, je pense avoir compris.
Pour ce qui est de "balancer" les questions de mon QCM, je ne vois où est le problème.
Je répond à ces questions en essayant d'argumenter et je les post ici afin qu'on me corrige. Le procédé me semble tout à fait correct.

Bref passons, à present j'ai une question sur les tableaux.

Tableau :
A : sa taille est donnée par la méthode sans argument lenght()
B : sa taille est donnée par la méthode sans arguent size()
C :comme le tableau est de type objet, ses élements sont toujours de type objet
D : ses élements peuvent être de différents types d'objets dans un contexte d'héritage
E : son premier élement a l'indice 0
F : l'affectation d'un tableau à un autre tableau entraine une recopie de ses élements
G : aucune des réponses precedentes

A : oui
B : non, size pour longueur d'un string
C : oui (mais je ne suis pas sûr)
D : oui, un tableau de différents objets héritant d'un même objet ---> polymorphisme
E : oui
F : je ne sais pas, mais je ne pense pas

[Rayndell]

A : la réponse est non. C'est un attribut length, pas une méthode.
B : non.
C : non. On peut construire des tableaux de type primitif comme int.
D : tout à fait.
E : certes.
F : que dalle, c'est juste une copie de référence.