Discussion :

[NeptuS]

non, ce n'est pas Eclipse, mais Java qui impose une seule classe publique par fichier.

[had35]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
/*Constructeur avec tableau*/
LaClassse(double[][] tab){
initArrayList(tab);
}
/*Constructeur avec fichier*/
LaClasse(String filePath){
...
initArrayList(tab);
}
void initArrayList(double[][] tab){
...
}

ça marche parfaitement, mais il n'est pas prudent d'appeler les méthodes non-statiques d'une classe dans un constructeur de cette même classe. Les méthodes non-statiques sont en effet susceptible d'accéder à des variables d'instance dont c'est le rôle du constructeur de les initialiser ...
Dans ton cas, étant donné qu'il n'est pas possible de déduire le chemin d'accès à partir du tableau ni inversement, sans quoi tu aurait uniquement recouru à la surcharge de constructeur, le mieux est donc de factoriser le code commun aux deux constructeurs dans une méthode statique. Ca ne change rien en l'état mais c'est plus propre.


Sinon question subsidiaire:
peut-on définir les méthodes d'une classe en dehors de celle ci comme en C++?[/QUOTE]

En C++, la déclaration des prototypes de méthodes et de classes oblige à utiliser un fichier d'entêtes, et donc de jongler avec deux fichiers pour écrire une seule classe, sauf pour les classes template. Je préfère largement la façon dont on organise le code en Java qui permet d'avoir une vue d'ensemble de sa classe dans un seul fichier.

[Pragmateek]

non, ce n'est pas Eclipse, mais Java qui impose une seule classe publique par fichier.

C'était le:

autant de classe non public que l'on veut.

qui fait oublier le fait qu'il faut une classe par fichier.

c'est le rôle du constructeur de les initialiser ...

En fait c'est ma fonction qui fait office de "constructeur" en initialisant les données.
Les vrais constructeurs se contentent de faire appel à cette fonction.

une méthode statique

Pourquoi static?

[NeptuS]

Pourquoi static?

Une simple méthode privée commune aux deux constructeurs suffit.


had35, j'ai beau largement mieux connaître Java que C#, je ne connais pas la réponse à ta dernière question. En revanche, je qu'il existe en C# la concept de classes partielles (partial) : il permet de délocaliser une partie de la définition de la classe.
C'est un axe à creuser ....

[had35]

Pourquoi static?

Ca n'a pas une importance énorme mais une méthode non-statique est sensée s'appliquer à un objet et peut donc accéder à ses variables d'état. Si l'appel de la méthode (dans le constructeur, donc) se fait avant que la variable ait été initialisée, l'erreur ne se verra qu'à l'exécution. La méthode factorisant le code commun aux deux constructeurs devrait bien sûr être private, mais en ajoutant static, on demande au compilateur de veiller au grain, il nous interdira d'accéder à une variable d'instance. Ca peut paraître un peut dogmatique, mais je trouve que l'intérêt de Java est justement d'offrir une syntaxe permettant de limiter au maximum que ne se glisse des petites erreurs de ce type.

En relisant le code, je constate d'ailleurs qu'en modifiant la méthode à static, celui-ci ne compilerait plus puisque l'idée, je suppose, était d'initialiser une ArrayList, membre de la classe. Une construction plus propre à mon avis serait donc d'avoir un constructeur prenant une List en argument et un constructeur sans argument, puis de fournir un méthode pour remplir l'ArrayList, une fois l'objet construit :

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
 
public class LaClasse {
 /*Constructeur avec tableau*/
 private List list;
 
 public LaClasse(List list) {
  this.list = list;
 }
 public LaClasse() {
  list = new ArrayList();
 }
 public void initArrayList(String filePath) throws IOException {
 }
 public void initArrayList(double[][] tab) {
 }
}

Ou bien d'étendre ArrayList et surcharger son constructeur :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
public class MaListe extends ArrayList {
 public MaListe(String filePath) throws IOException {
  super();
  ...
 }
 public MaListe(double[][]) {
  super();
  ...
 }
}

Mais bon, je pars sur autre chose

[Pragmateek]

Merci de ces précisions.

[RadicalBob]

On appel ça une interface

Hum... pas tout à fait en fait.

Justement, si une classe implements une interface quelconque elle doit en définir les methodes donc il faut bien les écrire quelque part.

A la limite c'est plus du coté de l'heritage qu'il faut réfléchir non ?

[NeptuS]

Justement, si une classe implements une interface quelconque elle doit en définir les methodes donc il faut bien les écrire quelque part.

Il me semble pas non ... que fais-tu des classes abstraites ?

[RadicalBob]

Il me semble pas non ... que fais-tu des classes abstraites ?

je n'y avais pas pensé il est vrai