Discussion :

[Kikito]

Bonjour,
J'ouvre cette discussion pour avoir un avis sur une question.

Dans le cas où une classe héritée par plusieurs autres classes déclare des variables et définit des méthodes non abstract pour ses enfants, mais qu'elle n'a aucune méthode abstract et que celle ci ne doit pas être instanciée, feriez vous une classe abstraite qui ne définit pas de méthode abstract ou une classe normale dont on met le constructeur en private ?

[mavina]

Bonjour,
J'ouvre cette discussion pour avoir un avis sur une question.

Dans le cas où une classe héritée par plusieurs autres classes déclare des variables et définit des méthodes non abstract pour ses enfants, mais qu'elle n'a aucune méthode abstract et que celle ci ne doit pas être instanciée, feriez vous une classe abstraite qui ne définit pas de méthode abstract ou une classe normale dont on met le constructeur en private ?

Salut,

Je dirait classe abstraite.
En effet, si tu mets une classe normale avec un constructeur privé, ca devient (presque) un singleton, il ne manquerai que la fonction getInstance().
Or ton but n'est pas de faire un singleton mais bien de faire une classe racine, qui définit des fonctions communes.
Je ne penses pas que le fait qu'il n'y ai pas de fonction abstraite soit un problème.

Cordialement

Fred

[manblaizo]

Bonjour,
A mon avis tout dépend si cela a véritablement un sens d'avoir une instance de cette classe de base. Si elle ne peut pas être instanciée parce que les seules classes concrètes ne pourraient être que les classes dérivées, alors le mot clé abstract est fait pour ça, même si la classe ne déclare aucune méthode abstraite. Par contre, si l'objectif est d'empêcher toute instanciation de cette classe en dehors de la classe elle-même, c'est-à-dire que l'on ne pourrait obtenir une instance de cette classe qu'en appelant une méthode de la classe elle-même, alors un constructeur private rentre en jeu, tout en fournissant une méthode public permettant d'obtenir une instance de la classe. C'est d'ailleurs comme ça que le pattern Singleton est souvent implémenter.

[Kikito]

Merci de vos réponses, c'est donc bien ce que je pensais, dans mon cas une classe abstraite est le mieux et ça avait été mon premier réflexe, mais c'est vrai que ça me faisait bizarre de n'avoir aucune méthode abstract.

Merci.

[Deadpool]

D'autant plus que, si je ne dis pas de bêtises, il est impossible d'hériter d'une classe concrète n'ayant que des constructeurs privés. Donc la classe abstraite est la seule solution.

[manblaizo]

Descent a écrit :

D'autant plus que, si je ne dis pas de bêtises, il est impossible d'hériter d'une classe concrète n'ayant que des constructeurs privés. Donc la classe abstraite est la seule solution.

Tout à fait !

[professeur shadoko]

un constructeur protected c'est bien aussi.
d'ailleurs j'ai tendance à penser que les classes abstraites ont quasi-automatiquement des constructeurs protected.
votre avis?

[herve91]

un constructeur protected c'est bien aussi.
d'ailleurs j'ai tendance à penser que les classes abstraites ont quasi-automatiquement des constructeurs protected.
votre avis?

De toute façon, protected ou public, ça ne changera pas grand chose :

Code :

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

1
2
3
4
5
6
7
public abstract class A {
  protected A() {...}
  protected A(int i) {...}
}
 
A a = new A() {};
A aa = new A(0) {};

[®om]

un constructeur protected c'est bien aussi.
d'ailleurs j'ai tendance à penser que les classes abstraites ont quasi-automatiquement des constructeurs protected.
votre avis?

Qu'est-ce que ça change un constructeur public ou protected pour une classe abstraite?

herve91, sur ton exemple, A est abstraite, tu peux pas faire new A()...

[adiGuba]

Salut,

Qu'est-ce que ça change un constructeur public ou protected pour une classe abstraite?

Cela ne change rien en effet...

herve91, sur ton exemple, A est abstraite, tu peux pas faire new A()...

Fais attention aux accolades derrière le new : {}
Cela signifie qu'il s'agit d'une classe anonyme (et donc d'une classe fille)

a++

[®om]

Fais attention aux accolades derrière le new : {}
Cela signifie qu'il s'agit d'une classe anonyme (et donc d'une classe fille)

Ah oui, bien vu, j'avais zappé la fin de la ligne

[®om]

Cela ne change rien en effet...

D'ailleurs, le protected semble être promu en public :

Code :

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

1
2
3
4
5
6
7
package autrepackage;
 
public abstract class AbstractClass {
 
    protected AbstractClass() {}
 
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
package unpackage;
 
import autrepackage.AbstractClass;
 
public class TestProtect {
 
    public static void main(String... args) {
        AbstractClass ac = new AbstractClass() {};
        // ça compile, alors que pas dans le même package (ni sous-classe)
    }
 
}

Ma conclusion est-elle bonne?

[adiGuba]

Ma conclusion est-elle bonne?

Non car il s'agit d'une classe anonyme, et tu appelles le constructeur de la classe anonyme (qui doit correspondre à la classe unpackage.TestProtect$1) et non pas celui de la classe abstraite...

Grosso modo ton code revient "presque" à faire ceci :

Code :

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

1
2
3
4
5
6
7
	 public static void main(String... args) {
		class Anonyme extends AbstractClass {
			// ...
		}
		;
		AbstractClass ac = new Anonyme();
	}

a++

[®om]

Non car il s'agit d'une classe anonyme, et tu appelles le constructeur de la classe anonyme (qui doit correspondre à la classe unpackage.TestProtect$1) et non pas celui de la classe abstraite...

Grosso modo ton code revient "presque" à faire ceci :

Code :

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

1
2
3
4
5
6
7
	 public static void main(String... args) {
		class Anonyme extends AbstractClass {
			// ...
		}
		;
		AbstractClass ac = new Anonyme();
	}

a++

OK merci de ces précisions

Dans ton exemple, le constructeur (par défaut) de Anonyme, il est public?

[adiGuba]

Dans ton exemple, le constructeur (par défaut) de Anonyme, il est public?

En fait il est de la même visibilité que la classe parente :



En fait il y a deux cas de figure :


Pour les classes "standard" sans constructeurs explicite, par exemple :

Code :

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

1
2
3
public class MaClasse {
 
}

Un constructeur par défaut est implicitement généré par le compilateur. Il se contente d'appeler le constructeur de la classe parente (Object par défaut). Ce qui fait que le code ci-dessus est strictement équivalent à :

Code :

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

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

La visibilité du constructeur est la même que de la visibilité de la classe parente :
http://java.sun.com/docs/books/jls/t...ses.html#8.8.9





Pour les "classes anonymes" c'est différent car on ne peut pas y déclarer de constructeur explicite. Ainsi on ne pourrait pas écrire ceci :

Code :

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

1
2
3
4
5
	MaClasse instance = new MaClasse() {
		MaClasse() {
			// redéfinition du constructeur impossible
		}
	};

En fait les classes anonymes on obligatoirement un constructeur implicite qui renvoi vers le constructeur de la classe parente avec les mêmes paramètres, c'est pourquoi avec une classe comme cela :

Code :

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

1
2
3
4
5
public abstract class MaClasseAbstraite() {
	public MaClasseAbstraite(String name, int id) {
		// ...
	}
}

On peut faire une classe abstraite comme cela par exemple :

Code :

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

1
2
3
MaClasseAbstraite instance = new MaClasseAbstraite("maString", 0) {
	// ...
}

Grosso modo le constructeur de la classe anonyme se contente de passer les paramètres au constructeur de la classe parente (MaClasseAbstraite ici).

Ceci est également décrit ici :
http://java.sun.com/docs/books/jls/t....html#15.9.5.1


a++