Architecture programme Java!!
Résolu/Fermé
seljazou
Messages postés
175
Date d'inscription
dimanche 6 septembre 2009
Statut
Membre
Dernière intervention
25 décembre 2009
-
30 nov. 2009 à 13:06
seljazou Messages postés 175 Date d'inscription dimanche 6 septembre 2009 Statut Membre Dernière intervention 25 décembre 2009 - 3 déc. 2009 à 03:46
seljazou Messages postés 175 Date d'inscription dimanche 6 septembre 2009 Statut Membre Dernière intervention 25 décembre 2009 - 3 déc. 2009 à 03:46
A voir également:
- Architecture programme Java!!
- Waptrick java football - Télécharger - Jeux vidéo
- Jeux java itel football - Télécharger - Jeux vidéo
- Logiciel architecture gratuit - Télécharger - Architecture & Déco
- Java apk - Télécharger - Langages
- Programme demarrage windows 10 - Guide
7 réponses
KX
Messages postés
16753
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
25 novembre 2024
3 020
30 nov. 2009 à 20:07
30 nov. 2009 à 20:07
Si tu fais un package (si tu sais ce que c'est) tu pourras créer plusieurs fichiers avec plusieurs classes à l'intérieur (au plus une classe publique par fichier) et toutes appartiendront à ton package.
Tant que tu es dans ton package, toutes les classes (y compris private) seront visibles par les classes et méthodes de classes du package, mais seules les méthode public d'une classe seront accessibles, les méthodes private étant réservées au seul usage d'une classe.
Si tu n'es plus dans le package, tu pourras accéder aux classes public du package en faisant import MonPackage, mais les classes private ne seront pas disponibles, elles sont réservées au seul usage du package.
Remarque : pour la composition de classe on pourrait aussi faire de l'héritage de classe, mais je crois que ce sera pas pour aujourd'hui ;-)
Tant que tu es dans ton package, toutes les classes (y compris private) seront visibles par les classes et méthodes de classes du package, mais seules les méthode public d'une classe seront accessibles, les méthodes private étant réservées au seul usage d'une classe.
Si tu n'es plus dans le package, tu pourras accéder aux classes public du package en faisant import MonPackage, mais les classes private ne seront pas disponibles, elles sont réservées au seul usage du package.
Remarque : pour la composition de classe on pourrait aussi faire de l'héritage de classe, mais je crois que ce sera pas pour aujourd'hui ;-)
KX
Messages postés
16753
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
25 novembre 2024
3 020
1 déc. 2009 à 10:34
1 déc. 2009 à 10:34
Tu interprètes ce que je dis et à mon avis tu le fais mal.
Mais tout dépend de ce que tu veux dire par "programme", moi je parlais uniquement de classes.
Lancer un programme en java c'est exécuter la méthode public static void main(String args[]) d'une classe publique.
Donc on peux créer dans le code des classes publiques mais pas plus d'une par fichier, et si tu as plusieurs classes public, il est conseillé de faire un package et de faire l'import du package (je pense qu'on peux faire sans en faisant un import de chaque fichier nécessaire mais c'est lourd).
Si tu veux réfléchir en terme de programme, voici une structure basique :
Mais tout dépend de ce que tu veux dire par "programme", moi je parlais uniquement de classes.
Lancer un programme en java c'est exécuter la méthode public static void main(String args[]) d'une classe publique.
Donc on peux créer dans le code des classes publiques mais pas plus d'une par fichier, et si tu as plusieurs classes public, il est conseillé de faire un package et de faire l'import du package (je pense qu'on peux faire sans en faisant un import de chaque fichier nécessaire mais c'est lourd).
Si tu veux réfléchir en terme de programme, voici une structure basique :
package MonProgramme; // dans tous les fichiers public class Point{} // dans un fichier Point.java, ne contient pas de méthode main public class Cercle{} // dans un fichier Cercle.java, ne contient pas de méthode main ... public class ProgrammePrincipal // dans un fichier ProgrammePrincipal.java { ... // peut contenir autre chose que la méthode main public static void main(String args[]){} // utilise les autres classes du package }
seljazou
Messages postés
175
Date d'inscription
dimanche 6 septembre 2009
Statut
Membre
Dernière intervention
25 décembre 2009
1
1 déc. 2009 à 10:43
1 déc. 2009 à 10:43
Désolée je suis desespérante :s
une dernière question et ça sera fini, dans la classeProgrammePrincipal, a t on le droit de definir des classes publiques???? pourrons nous les definir an haut près des imports? ou bien on n'a le droit que de les importer?
désolée et merci
une dernière question et ça sera fini, dans la classeProgrammePrincipal, a t on le droit de definir des classes publiques???? pourrons nous les definir an haut près des imports? ou bien on n'a le droit que de les importer?
désolée et merci
KX
Messages postés
16753
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
25 novembre 2024
3 020
1 déc. 2009 à 13:10
1 déc. 2009 à 13:10
Tu ne peux pas définir de classes public dans la classe de ProgrammePrincipal car ta classe ProgrammePrincipal est public et qu'on ne peut définir des classes public que dans des fichiers distincts.
Sinon tu vas te faire engueuler par le compilateur, et en anglais en plus ;-)
De plus on ne peux pas définir des classes à l'intérieur d'autres classes, ce serait contraire à la modularité.
Par contre tu peux faire appel à un package et/ou importer des classes public et/ou définir des classes private après les import (et avant ta classe public)
Dans l'ordre ça donnerait :
Sinon tu vas te faire engueuler par le compilateur, et en anglais en plus ;-)
De plus on ne peux pas définir des classes à l'intérieur d'autres classes, ce serait contraire à la modularité.
Par contre tu peux faire appel à un package et/ou importer des classes public et/ou définir des classes private après les import (et avant ta classe public)
Dans l'ordre ça donnerait :
package Exercice1; import java.util; // par exemple class Intermediaire1 {} // private class Intermediaire2 {} // private public class ProgrammePrincipal { ... // méthodes spécifiques à la classe public static void main(String args[]) { ... } }Et bien entendu ce code serait dans un fichier portant le même nom que la classe public : ProgrammePrincipal.java
seljazou
Messages postés
175
Date d'inscription
dimanche 6 septembre 2009
Statut
Membre
Dernière intervention
25 décembre 2009
1
1 déc. 2009 à 21:38
1 déc. 2009 à 21:38
compris!!! merci beaucoup beaucoup. Je te suis très reconnaissante.
C'est clair maintenant. encore merci.
C'est clair maintenant. encore merci.
seljazou
Messages postés
175
Date d'inscription
dimanche 6 septembre 2009
Statut
Membre
Dernière intervention
25 décembre 2009
1
>
seljazou
Messages postés
175
Date d'inscription
dimanche 6 septembre 2009
Statut
Membre
Dernière intervention
25 décembre 2009
2 déc. 2009 à 00:51
2 déc. 2009 à 00:51
j'abuse je sais :s mais une toute dernière question si tu veux bien.
POur les méthodes; il y a deux types:
1- méthodes de classe, précédées de static.
2- méthodes d'instance, applicables seulement aux objets.
S'il te plait, j'aimerai savoir si on peut definir les deux types de méthodes entre notre classe et la fonction main. C'est ce que j'ai vu dans plusieurs exemples. OU bien a t on juste le droit de les definir dans notre classe, à fur et à mesure qu'on en a besoin.
Et n y a t il pas des bibliothèques de méthodes comme dans le C ?
ça serait vraiement très gentil de ta part de me répondre.
Merci pour toutes tes réponses, grace à toi jy vois plus clair.
POur les méthodes; il y a deux types:
1- méthodes de classe, précédées de static.
2- méthodes d'instance, applicables seulement aux objets.
S'il te plait, j'aimerai savoir si on peut definir les deux types de méthodes entre notre classe et la fonction main. C'est ce que j'ai vu dans plusieurs exemples. OU bien a t on juste le droit de les definir dans notre classe, à fur et à mesure qu'on en a besoin.
Et n y a t il pas des bibliothèques de méthodes comme dans le C ?
ça serait vraiement très gentil de ta part de me répondre.
Merci pour toutes tes réponses, grace à toi jy vois plus clair.
KX
Messages postés
16753
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
25 novembre 2024
3 020
2 déc. 2009 à 06:08
2 déc. 2009 à 06:08
On doit définir les méthodes à l'intérieur de la classe, et ce quelques soit leurs paramètres (public, private, protected, static, final, abstract...) mais on peut mélanger les paramètres et même les combiner, regarde par exemple la méthode public static void main(String[] args); qui en est un exemple parfait.
Et bien évidemment il y a des bibliothèques fourni en Java (on les utilise avec import) mais ce ne sont pas des bibliothèques de fonctions comme en C (parler de méthode n'a pas de sens en C), mais de classes comme en C++
Pour cela, il te faut absolument mettre le site de documentation Java en raccourci sur ton navigateur internet parce qu'il va bientôt devenir ton meilleur (ou pire) ami !
JDK Programmer Guides : https://www.oracle.com/java/technologies/javase-documentation.html
Choisi la version de la doc qui correspond à ta version de java (java -version) parce qu'il y a eu beaucoup d'évolutions.
Au début tu seras un peu perdu dans toute cette documentation mais il faut absolument s'y lancer car c'est un outil fondamental de la programmation Java (sinon il faudrait réinventer la roue à chaque fois) et que tu seras au point, tu feras toi même ta propre documentation avec javadoc !
Et bien évidemment il y a des bibliothèques fourni en Java (on les utilise avec import) mais ce ne sont pas des bibliothèques de fonctions comme en C (parler de méthode n'a pas de sens en C), mais de classes comme en C++
Pour cela, il te faut absolument mettre le site de documentation Java en raccourci sur ton navigateur internet parce qu'il va bientôt devenir ton meilleur (ou pire) ami !
JDK Programmer Guides : https://www.oracle.com/java/technologies/javase-documentation.html
Choisi la version de la doc qui correspond à ta version de java (java -version) parce qu'il y a eu beaucoup d'évolutions.
Au début tu seras un peu perdu dans toute cette documentation mais il faut absolument s'y lancer car c'est un outil fondamental de la programmation Java (sinon il faudrait réinventer la roue à chaque fois) et que tu seras au point, tu feras toi même ta propre documentation avec javadoc !
seljazou
Messages postés
175
Date d'inscription
dimanche 6 septembre 2009
Statut
Membre
Dernière intervention
25 décembre 2009
1
3 déc. 2009 à 03:46
3 déc. 2009 à 03:46
vivement ! ! !
Merci beaucoup, grace à toi l'architecture Java me semble moins floue, disant même que je commence à apprécier Java!!
Milles remerciements !!!
Merci beaucoup, grace à toi l'architecture Java me semble moins floue, disant même que je commence à apprécier Java!!
Milles remerciements !!!
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
KX
Messages postés
16753
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
25 novembre 2024
3 020
30 nov. 2009 à 13:37
30 nov. 2009 à 13:37
Salut, petites réponses rapides...
1. oui, comme en C ou presque
2. les import ce sont des librairies comme les include, mais la librairie la plus utilisée (java.lang) est toujours inclus par défaut ce qui t'évite d'avoir à l'appeler à chaque fois
3. une méthode private ne l'est qu'en dehors de la classe, si ton main est dans la classe, toute les méthodes de la classe (y compris private) seront disponible
une classe private ne l'est qu'en dehors du package, toute classe du package y aura accès
4. java.lang est inclu par défaut comme je l'ai déjà dit en 2
Bonne chance !
1. oui, comme en C ou presque
2. les import ce sont des librairies comme les include, mais la librairie la plus utilisée (java.lang) est toujours inclus par défaut ce qui t'évite d'avoir à l'appeler à chaque fois
3. une méthode private ne l'est qu'en dehors de la classe, si ton main est dans la classe, toute les méthodes de la classe (y compris private) seront disponible
une classe private ne l'est qu'en dehors du package, toute classe du package y aura accès
4. java.lang est inclu par défaut comme je l'ai déjà dit en 2
Bonne chance !
seljazou
Messages postés
175
Date d'inscription
dimanche 6 septembre 2009
Statut
Membre
Dernière intervention
25 décembre 2009
1
30 nov. 2009 à 19:41
30 nov. 2009 à 19:41
Pour la question 3 , si j'ai bien compri :
Si une méthode est private --> elle est utilisable seulement dans la classe qui lui correspond.
Mais pour une classe private, j'ai pas bien compris. est ce qu'on peut avoir une classe composée d'une autre classe?
Mais merci pour les autres reponses :) c t précis et clair.
Si une méthode est private --> elle est utilisable seulement dans la classe qui lui correspond.
Mais pour une classe private, j'ai pas bien compris. est ce qu'on peut avoir une classe composée d'une autre classe?
Mais merci pour les autres reponses :) c t précis et clair.
KX
Messages postés
16753
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
25 novembre 2024
3 020
30 nov. 2009 à 20:29
30 nov. 2009 à 20:29
C'est ça à part le premier point :
Un fichier .java doit TOUJOURS porter le même nom que la classe public qu'il contient - s'il en contient une - et c'est pour ça qu'on ne peut mettre qu'une seule classe public par fichier.
Par contre on peut mettre autant de classes private que nécessaire dans ce fichier.
Ceci est toujours vrai, que le fichier soit dans un package ou non.
Par contre un package "relie" les différents fichiers (et surtout les classes qu'il contient) comme s'il n'y avait qu'un seul et unique fichier.
Un fichier .java doit TOUJOURS porter le même nom que la classe public qu'il contient - s'il en contient une - et c'est pour ça qu'on ne peut mettre qu'une seule classe public par fichier.
Par contre on peut mettre autant de classes private que nécessaire dans ce fichier.
Ceci est toujours vrai, que le fichier soit dans un package ou non.
Par contre un package "relie" les différents fichiers (et surtout les classes qu'il contient) comme s'il n'y avait qu'un seul et unique fichier.
seljazou
Messages postés
175
Date d'inscription
dimanche 6 septembre 2009
Statut
Membre
Dernière intervention
25 décembre 2009
1
30 nov. 2009 à 20:39
30 nov. 2009 à 20:39
tu es sure que quand un fichier du package, il n y a qu'une seule classe public, les autres private?
Je crois qu'on peut utiliser d'autres classes publics en plus de celle qui a le même nom que notre fichier .java.
Mais c'est qu'une intuition :D puisque dans les codes normaux on fait ça, ça doit être le cas pour les fichiers du package.
merci pour ton attention et réponses.
:)
Je crois qu'on peut utiliser d'autres classes publics en plus de celle qui a le même nom que notre fichier .java.
Mais c'est qu'une intuition :D puisque dans les codes normaux on fait ça, ça doit être le cas pour les fichiers du package.
merci pour ton attention et réponses.
:)
KX
Messages postés
16753
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
25 novembre 2024
3 020
30 nov. 2009 à 21:55
30 nov. 2009 à 21:55
Je suis sûr effectivement et voici quelques tests pour t'en convaincre :
a) Test.java :
b) Test1.java :
c) Test2.java :
Et voici les messages d'erreurs à la compilation
a)
b)
c)
L'interprétation est assez évidente et revient à ce que j'ai dit, si les classes sont public elles DOIVENT être dans un fichier à part qui porte le même nom que la classe sinon javac commence à parler anglais (exemples a et b).
Par contre on peux avoir une classe public et une (ou plusieurs) classe private sans problème tant que le fichier porte le nom de la classe publique (exemple c)
Et ceci est TOUJOURS valable, package ou non...
Remarque : si un fichier ne contient que des classes private, le nom du fichier importe peu du moment qu'il a l'extension .java
a) Test.java :
public class Test1 {} public class Test2 {}
b) Test1.java :
public class Test1 {} public class Test2 {}
c) Test2.java :
class Test1 {} public class Test2 {}
Et voici les messages d'erreurs à la compilation
a)
>javac Test.java class Test1 is public sould be declared in file named Test1.java class Test2 is public sould be declared in file named Test2.java
b)
>javac Test1.java class Test2 is public sould be declared in file named Test2.java
c)
> javac Test2.java // pas d'erreur
L'interprétation est assez évidente et revient à ce que j'ai dit, si les classes sont public elles DOIVENT être dans un fichier à part qui porte le même nom que la classe sinon javac commence à parler anglais (exemples a et b).
Par contre on peux avoir une classe public et une (ou plusieurs) classe private sans problème tant que le fichier porte le nom de la classe publique (exemple c)
Et ceci est TOUJOURS valable, package ou non...
Remarque : si un fichier ne contient que des classes private, le nom du fichier importe peu du moment qu'il a l'extension .java
seljazou
Messages postés
175
Date d'inscription
dimanche 6 septembre 2009
Statut
Membre
Dernière intervention
25 décembre 2009
1
1 déc. 2009 à 02:47
1 déc. 2009 à 02:47
donc d'après ce que tu as dit, dans chaque programme on n'a pas le droit de créer dans le code des classes public ( les definir) mais plutot si on en a besoin on les appele avec le import. Et pour cela , on crée ( ou on a deja crée ) un fichier qui porte uniquemen cette classe (cette dernière a le mm nom que le fichier .java).
J'espère que c ça.
ET puis une autre chose, je croyais que le code est toujours écrit dans la fonction main, mais sur le site du zero, j trouvé qu'il faut pas que ça soit dans le main. Je suis perdue grave !!!
J'espère que c ça.
ET puis une autre chose, je croyais que le code est toujours écrit dans la fonction main, mais sur le site du zero, j trouvé qu'il faut pas que ça soit dans le main. Je suis perdue grave !!!
30 nov. 2009 à 20:18
un package = ensemble de fichiers tels que chaque fichier contient UNE classe ( private ou public ou autre).
Si on est en train d'ecrire des fichiers dans le package, on aura le droit de faire appel à toutes les classes de ce dernier ( même les private).
Si on est en dehors du package, on accès au classes public grace à import, sinon pour les classes private, c impossible.
ça me semble logique, j'espère que c ça :)