Bonjours à tous,
je me met à java ( pour utiliser un super environnement basé sur tomcat).
et j'ai quelques questions simples des l'instant ou je veux utiliser plus d'une classe.
1) Si j'ai bien compris c'est une classe par fichier qui porte le nom du fichier.
2) Je met toute mes classes qui vont ensemble dans le même répertoire qui porte le nom du package, puis j'importe mon package dans mon programme principal via import c'est bien ça ?
3) Une classe sans constructeur avec juste des variables dedans ( façon structure) ça marche aussi hein ? S'agit t'il d'une pratique à proscrire ou non ?
4) Si je met tout un tas de fonctions utiles dans une classe puis-je les appelées sans pour autant avoir une instance de ma classe qui existe ( Bref je cherche un équivalent d'un namespace en C++) ou dois je absolument crée une instance d'une classe ( que nous appelerons myUtil ) pour pouvoir appeler ces fonctions.
5) java connaît pas les unsigned, il faut donc prendre des conteneurs plus gros, on trouve des explications sur comment convertir des unsigned int en long par la manipulation bit à bit, mais il n'y a pas une fonction standard pour faire ça ?
Bon j'ai encore d'autre question mais ce sera tout pour ce post là
Merci aux ``J2EE lead architect'' pour leurs réponses
Forum Programmation.java Classes fichiers, 5 questions simples
11
août
2008
# quelques éléments de réponse
Posté par santos . Évalué à 3.
je ne suis pas spécialise J2EE, mais je connais un peu Java tout court.
try {
1) oui - la classe MyClass doit être dans le fichier MyClass.java, elle doit être publique et doit être la première classe du fichier.
public class MyClass {
2) oui - mais d'abord :
cd repertoire/contenant/les/classes/
jar cvf MonArchive.jar *.class
3) oui -- oui :-)
4) oui - c'est ce qu'on appelle une classe statique, qui contient des méthodes statiques.
Pour les appeler :
myUtils.taMethodeStatique()
Pour cela, la ma méthode doit être déclarée statique :
static Type taMethodeStatique()
}
catch (connerie c)
{
c.parent.pasTaper();
c.corriger();
}
[^] # Re: quelques éléments de réponse
Posté par Mais qui suis-je ? :) . Évalué à 2.
Fichier monFich try { monFich = new Fichier // on ouvre le fichier } catch { // on récupère une eventuelle exception puis System.exit(-1) } plus loins je veux lire le fichier try { monFich.Read() } catch { // Pas fichus de lire un fichier }Mais je fais comme ça java me répond que il y a un risque que monFich soit pas déclaré et que par conséquent il ne compile pas il faut donc que je fasse un truc du genreFichier monFich try { // on ouvre try { // on lit } catch { /*sais pas lire*/} catch { /*sais pas ouvrir*/}La par contre ça compile Au bout de quelques try imbriqué ça devient vite peu lisible ( et pour peu qu'il y ait un if et une boucle fort, on indente jusqu'au bout de l'écran) La question qui tue c'est comment je fais ça proprement, pour ne pas me faire insulter d'un coté et d'autre part ne pas imbriqué plus de try/catch que de raison ?[^] # Re: quelques éléments de réponse
Posté par Octabrain . Évalué à 3.
Fichier fic; try { fic = new Fichier(...); fic.read(); ... } catch(...) { // Erreur : ... } finally { if (fic != null) { fic.close(); } // autre liberations eventuelles }Évidemment, on sait moins quelle opération du fichier a loupé.# Formation?
Posté par wismerhill . Évalué à 3.
Tu devrais suivre un cours (ou un tutoriel) d'initiation de base à java, ça t'évitera de venir poser des centaines de questions de base sur des forums.
Pour être constructif, je vais quand même répondre:
1) Pour les classes publiques oui, les classes package private peuvent être dans le même fichier, mais c'est considéré comme une mauvaise pratique.
2) Oui, mais il faut aussi déclarer le package au début des fichiers.
3) Une classe à toujours un constructeur, si tu n'en fourni pas le compilateur s'en charge pour toi (avec un constructeur public sans argument). Si tu veux une classe "sans constructeur", défini explicitement un constructeur privé.
4) Oui, les méthodes doivent être statiques.
5) Les unsigned n'existent pas en java, donc tu n'a pas besoin de t'en soucier. Sauf si tu veux faire la liaison avec des méthodes natives, mais commence d'abord par maîtriser java avant d'essayer le JNI.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.