Forum Programmation.java Classes fichiers, 5 questions simples

Posté par  .
Étiquettes : aucune
0
11
août
2008
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
  • # quelques éléments de réponse

    Posté par  . Évalué à 3.

    salut,

    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  . Évalué à 2.

      Merci pour ces réponses. Une autre question simples : Les exception c'est certainement génial une fois bien maitrisé mais comment faire pour que ca nuise le moins possible a la lisibilité du code ? Je m'explique ( en pseudo code)
       
      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 genre
       
      Fichier 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  . Évalué à 3.

        Normalement on fait plutôt comme ça, je crois :
        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  . Évalué à 3.

    C'est pas des questions de "J2EE" mais de formation de base en java.
    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.