non, ce n'est pas Eclipse, mais Java qui impose une seule classe publique par fichier.
non, ce n'est pas Eclipse, mais Java qui impose une seule classe publique par fichier.
ç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 ...
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){ ... }
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.
C'était le:non, ce n'est pas Eclipse, mais Java qui impose une seule classe publique par fichier.
qui fait oublier le fait qu'il faut une classe par fichier.autant de classe non public que l'on veut.
En fait c'est ma fonction qui fait office de "constructeur" en initialisant les données.c'est le rôle du constructeur de les initialiser ...
Les vrais constructeurs se contentent de faire appel à cette fonction.
Pourquoi static?une méthode statique
Une simple méthode privée commune aux deux constructeurs suffit.Envoyé par seriousme
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 ....
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.Envoyé par seriousme
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 :
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
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) { } }
Mais bon, je pars sur autre chose
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(); ... } }
Merci de ces précisions.
Hum... pas tout à fait en fait.Envoyé par Alwin
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 ?
Il me semble pas non ... que fais-tu des classes abstraites ?Envoyé par RadicalBob
je n'y avais pas pensé il est vraiEnvoyé par NeptuS
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager