Appel d'un constructeur à partir d'un autre

Salut!:D

Dans une classe j'ai deux constructeurs:
-un qui prend en parametre un tableau de type "double[][]" et le converti en "ArrayList".
-un qui prend en parametre un nom de fichier et en extrait les données qu'il stocke dans un tableau de type "double[][]".

Ce qu'il faudrait c'est que après avoir fait le tableau le 2ème constructeur fasse appel au 1er pour le convertir en "ArrayList", le 2ème ne faisant que "préparer le terrain".

Mais:

Code:

---

LaClasse(tab);

---

à la fin du 2ème constructeur donne l'erreur:

Code:

---

The method LaClasse(double[][]) is undefined for the type LaClasse

---

Est-il possible d'appeler un constructeur à partir d'un autre?
Si oui quelle est la procédure à suivre?

Merci de votre aide.:D

Pour appeler un constructeur apartir d un autre if faut utiliser le mot cle this. et par exemple tu devras faire this(double[][]).
Mais si je ne me trompe pas, il faut que cet appel soit la premiere instruciton dun constructeur pour qu elle puiss entre utilisee.
Pour quoi ne pas mettre le code qui effectue la transformation dans une methode qui effectue la transformation que tu appellerais depuis le constructeur directement au lieu de passer par des appel de differents constructeurs? Ca serait peut etre plus simple;)

Oui c'est possible avec le mot clé "this", par exemple :

Code:

---

1 2 3 4 5 6 7 8

MaClasse(A a, B b) { this(a); ... } MaClasse(A a) { ... }

---

Citation:

---

il faut que cet appel soit la premiere instruciton dun constructeur pour qu elle puiss entre utilisee.

---

Je m'en suis aperçu à mes dépends.

Citation:

---

Pour quoi ne pas mettre le code qui effectue la transformation dans une methode qui effectue la transformation que tu appellerais depuis le constructeur directement au lieu de passer par des appel de differents constructeurs? Ca serait peut etre plus simple

---

Sûrement mais je me demandais si je pouvais le faire sans réorganiser le code.
De plus il faut bien 2 constructeurs distincts.
J'avais pensé à "alléger" les constructeurs afin qu'il se contentent de faire appel aux méthodes qui effectueront l'initialisation effective des données.

Pour l'instant:

Code:

---

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){ ... }

---

qui marche parfaitement.

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

arghhhhhh:arf: vient pas dire ca ici ....

en java tout ce qui compose une classe est code dans la classe.

Tu peux faire des classes abstraites dont les methods abstraites seront obligatoirement implementees par les sous classes qui la derive, ou des interfaces qui declarent des methodes que les classes qui les implementent devront implementer mais sinon NON, il n est pas possible, en tout cas pas que je sache ...

> peut-on déclarer les méthodes d'une classe en dehors de celle ci comme en C++?

on peut faire ca en C++?
je croyais que la declaration de toute les methodes d'une classe etait obliger d'etre dans le .h ou .hpp
et l'implementation d'un un fichier .C ou .CPP. (ou dans le .h/hpp mais souvent on divise)?

ca a changer?
on peut definir une methode d'une classe dans une autre classe?

je pense que pour lui les mettre dans le .h ou .hpp c etait les mettre en dehors de la classe :)

Citation:

---

on peut faire ca en C++?
ca a changer?

---

A priori non c'est moi qui écrit des conneries.:aie:
Je veux dire DEFINIR.

merci pour ses precision :-)

Alors peut on les définir en dehors pour clarifier le code de la classe?

NON, en java le code d une classe est contenue dans la classe elle-meme. C est pas du C++:D
Et d ailleurs je trouve ca mieux d ailleurs, mais c est une opinion perso...

Dommage, ça fait plus propre une classe réduite aux déclarations.
Merci de vos réponses.

Ben je sais pas, une classe decoupee en plusieurs fichiers c est pas forcement genial...
Mais tu peux avoir la possibilite de faire des interfaces qui declarent des methodes, puis des classes qui vont implementer ces interfaces...
Masi bon perso je trouve que c es tmieux de bien avoir toutes ses methodes dans sa classe... mais comme le disent beaucoup, on ne progamme pas en Java comme on programme en C++ ...;)

On appel ça une interface ;)

Code:

---

1 2 3 4

public interface MonInterface { public void maMethode(); }

---

Code:

---

1 2 3 4 5 6

public class MaClasse implements MonInterface() { public void maMethode() { System.out.println("inside maMethode..."); } }

---

Code:

---

1 2 3 4 5

public static void main(String[] args) { MonInterface test = new MaClasse(); test.maMethode(); }

---

quoi de mieux qu un exemple pour illustrer un concept! bravo alwin!;)

Citation:

---

On appel ça une interface

---

Ce que je veux dire c'est:

Code:

---

1 2 3 4 5 6 7 8

class LaClasse{ ... void f(); ... }; void Laclasse::f(){ ... }

---

Mais c'est vrai que en Java les classes public ont chacune leur fichier ce qui réduit l'intérêt de la chose.

J'avais bien compris, mais bon ca c'est du C++ (pouah !!!) et la c'est du java, et je rappelle qu'on ne programme pas en Java comme on programme en C++...
Tout au meme endroit pour que ca soit plus dans l'esprit objet qu'en C++ (l'objet contient bien ses attributs et ses comportements et ceci meme physiquement) sans avoir la classe découplée de l'implémentation de ses comportements.

Citation:

---

Envoyé par seriousme

Mais c'est vrai que en Java les classes public ont chacune leur fichier ce qui réduit l'intérêt de la chose.

---

Y'a pas que les classes publiques, pour toutes les classes c'est pareil!

Citation:

---

Y'a pas que les classes publiques, pour toutes les classes c'est pareil!

---

Merci.
C'est parce que Eclipse autorise une seule classe public par fichier mais autant de classe non public que l'on veut.

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

Code:

---

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 ...:fou:
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.

Citation:

---

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

---

C'était le:

Citation:

---

autant de classe non public que l'on veut.

---

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

Citation:

---

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.

Citation:

---

une méthode statique

---

Pourquoi static?

Citation:

---

Envoyé par seriousme

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 ....

Citation:

---

Envoyé par seriousme

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:

---

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:

---

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 :mrgreen:

Merci de ces précisions.

Citation:

---

Envoyé par Alwin

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 ?

Citation:

---

Envoyé par RadicalBob

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 ?

Citation:

---

Envoyé par NeptuS

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

---

je n'y avais pas pensé il est vrai :aie: