Forum Programmation.java portée des méthodes

Posté par  .
Étiquettes : aucune
-1
18
nov.
2010
Bonjour à tous,

Je débute en Java et j'ai pour exercice de réaliser une mini calculatrice qui ne prend pas en compte les priorités dans les opérations. Voici le code d'une class Calto qui comprend la définition d'une méthode calculate(String arg) qui prend comme paramètre une chaine de caractère et étudie cette chaine mot par mot pour identifier l'opération demandé et la réalisé.

Le code ci-dessous ne marche pas. Eclipse me dit qu'il y a un problème lors de la définition de mes méthodes auxiliaires. Il y a un problème de porté des méthodes auxiliaires. Le problème se situe dans les mots clef public static je pense. Mais je ne sais pas comment résoudre le pb.

Merci de votre aide.

public class Calto {

/* Nous allons développer une calculatrice.*/

public static double calculate(String arg){


//Définition des variables;

//variable d'opération. Peut être : 1, 2, 3 ou 4 correspondant respectivement à +, -, /, x
int op = 0;

//Variable de lecture : 0 si la dernière lecture était un chiffre. 1 sinon
int lec = 0;

//variable résultat
double res = 0;

//Définition des méthodes auxiliaires.

//On vérifie que l'élément est bien une opération
public static boolean isOp(String v){

if(v == "+" || v == "-" || v == "/" || v == "*"){
return true;

}
else{
return false;
}

}

//On sait que l'élément est un opérateur. Mais lequel?
public static boolean whichOp(String v){
if(v=="+"){
op = 1;
}
else{
if(v=="-"){
op = 2;
}
else{
if(v=="/"){
op = 3;
}
else{
if(v=="*"){
op = 4;
}
}
}
}
}


//On parcours l'ensemble des éléments constituant l'expression à évaluer
String[] t = arg.split(" ");

for(String v : t){

//Soit l'élément est une opération...
if(isOp(v)){
op = whichOp(v);
lec = 1;
}

//Soit l'élément est un chiffre
if(isNumeric(v)){
if(lec==0){
res = Integer.parseInt(v);
}
else{
if(lec==1){
res = makeOp(res, op, Integer.parseInt(v));
}
}
}
}

}
  • # argggg

    Posté par  . Évalué à 2.

    quel style atroce
    else {
     if () {
     }
     else {
       if {

    if(){
      bla bla bla
    } else if (){
      blah
    } else if ( ){
      truxc
    }
    bon je ne vais pas refaire le cours, mais en gros un membre statique est commun à toutes les instances de la classe, et toutes les fonctions peuvent y accéder.

    Les fonction statique sont commune à toutes les instances de la classe; à partir de ce moment là, comment savoir à quel
    double res;
    elles doivent se référer ?
    Donc tu vire les static devant les fonctions qui se servent des variables membres non statique.

    enfin whichOp devrait retourner un enum (ou au pire un int) soit renvoyer une valeur du style -1 ou 0 si inconnu, ou mieux fait un throw (plus java compilant on va dire) )
    (et oui whichOp peut être statique, mais pas avec cette implémentation)

    PS : ceci s'adresse à tout ces fana d'éclipse qui corrige tout seul le code
    Alors elle est ou cette correction automatique?

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: argggg

      Posté par  . Évalué à 1.

      Merci pour ton aide.


      Pour le style, je sais. Mais c'est que l'exercice que je fais intervient avant la partie du coup ou on apprend le "elseif". Je respecte les hypothèses de départ. C'est relou mais bon...

      Pour le reste, j'ai viré les "static" mais rien ne change... :(
      • [^] # Re: argggg

        Posté par  . Évalué à 2.

        en fait je viens de faire un copier coller dans mon emacs favoris, et j'ai calculate (la fonction) dans laquelle est déclaré les autres fonction.

        C'est une erreur de copie ou il manque une accolade fermante ? (en général on déclare pas de fonction dans les autres fonctions )

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: argggg

          Posté par  . Évalué à 1.

          Pour l'accolade, c'est surement une erreur de copie.

          en général on déclare pas de fonction dans les autres fonctions

          C'est exactement ma question !!

          J'ai une grosse fonction. Qui fait plein de truc. Pour faciliter le développement je veux diviser les actions de ma fonction. Comment je fais?

          Exemple : ma fonction calculate doit fait 4 choses. Elle commence par diviser la chaine de caractère avec split. Ensuite j'analyse chaque éléments du tableau. Pour chaque élements je veut vérifier si l'élément est un caractère du type +, -, / ou *. Pour ne pas encombrer ma fonction calculate je veut diviser le travail en créant une fonction auxiliaire "isOp" qui vérifie que le caractère répond bien au contrainte. Je renvoie Vraie ou Faux.

          J'ai du mal à imaginer que ça ne soit pas possible...
          • [^] # Re: argggg

            Posté par  . Évalué à 0.

            class MaClasse {
            void maGrosseMethode() {
            maPetiteMethodeUn();
            maPetiteMethodeDeux();
            }

            void maPetiteMethodeUn() {
            }

            void maPetiteMethodeDeux() {
            }
            }
          • [^] # Re: argggg

            Posté par  . Évalué à 1.

            bien sur que c'est possible

            class jeCalculePourMoi{

            /* définition des variables membres */

            /* définition du/des constructeurs */

            /* définition des fonctions */
            bool isOp(Pouet machintruc){

            }
            bool bidulde( Pipo vouch ){
            System.out.println(" plop" + isOp(null) );
            }
            ....

            }

            C'est le principe du découpage en classe :)

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: argggg

              Posté par  . Évalué à 1.

              Ouais, ce que tu décris c'est exactement ce que j'ai fais dans mon code. et Eclipse me sort une erreur sur la ligne "boolean isOp(String v)"

              Multiple markers at this line
              - Syntax error on token ")", ;
              expected
              - Syntax error on token "(", ;
              expected

              ...
              • [^] # Commentaire supprimé

                Posté par  . Évalué à 2.

                Ce commentaire a été supprimé par l’équipe de modération.

  • # Comparaison de chaine

    Posté par  . Évalué à 2.

    L'intérêt de l'exercice c'est aussi que tu comprennes tout seul ce qui ne va pas.

    Pour commencer il ne faut pas utiliser v=="+" pour comparer les string comme tu le fais, mais la méthode equals() de la classe String. Enfin tu peux utiliser ==, mais ça ne signifie pas la même chose (dans ton cas ça marchera ptet (je ne suis pas sur) grâce (à cause?) d'une optimisation obligatoire des machines virtuelles Java).

    Donc v.equals("+"), ou plutôt "+".equals(v) qui a l'avantage de marcher même si v est null.
    • [^] # Re: Comparaison de chaine

      Posté par  . Évalué à 2.

      "+".equals(v)
      Quelle horreur !
      Quand on pense que des langages aussi vieux que java et bien plus performants permettent de redéfinir les opérateurs pour que les choses signifient ce qu'elles ont vraiment l'air de vouloir dire...
      • [^] # Re: Comparaison de chaine

        Posté par  . Évalué à 1.

        C'est un choix.

        Au moins quand tu vois un extrait de code Java avec == entre 2 String, tu sais ce que ça veux dire sans avoir à aller voir autre part si ça a été redéfini ou non. C'est pas toujours une erreur.
        • [^] # Re: Comparaison de chaine

          Posté par  . Évalué à 2.

          en même temps en java mon préféré reste

          Integer a= new Iteger(126);
          Integer b= new Iteger(126);

          System.out.println(a==b ) ; // false
          a++;
          b++;
          System.out.println(a==b ); // true
          a++;
          b++;
          System.out.println(a==b ); // false

          c'est t'y pas joli :)
          et faut se farcir la norme pour le voir la blague.

          - java 5 powa !!! -

          Pour les néophytes, c'est un problème d'auto boxing/unboxing avec valeur mutualisé entre -128 / +127 si je me souviens bien.

          Quand on force les new Integer, les références sont différente
          calcul, 127 - valeur mutualisé, les référence pointent au même endroit.
          re calcul
          > 127, référence non mutualisés.

          Et ça c'est quand même sacrément gênant, on fait les tests sur une 100 aine de valeurs, à la main on vérifie (c'est déjà bien), on passe en prod, paf ça plante.

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: Comparaison de chaine

            Posté par  . Évalué à 2.

            > on fait les tests sur une 100 aine de valeurs, à la main on vérifie (c'est déjà bien), on passe en prod, paf ça plante.

            En même temps si on test l'égalité entre 2 objets avec l'opérateur prévu par le langage pour tester l'égalité entre 2 références, bah faut pas s'étonner d'avoir des emmerdes...

            L'exemple est joli. J'ai été élevé avec les première version de Java et ça fait bizarre de voir l'opérateur ++ appliqué à un objet...
            • [^] # Re: Comparaison de chaine

              Posté par  . Évalué à 2.

              oh t'es pas obliger de passer par ++, en fait n'importe quelle opération qui donne un résultat entre -128 et +127 va avoir ce soucis.
              et on ne peut même pas dire que == en java est équivalent de &objet1 == &objet2 en c++.

              vu que pour les entier (1 == 2) c'est les valeurs qu'on teste...

              ils auraient mieux fait d'avoir un == normal et un equalsRef() équivalent à leur == on aurait pas ce mélange des genres.

              Il ne faut pas décorner les boeufs avant d'avoir semé le vent

              • [^] # Re: Comparaison de chaine

                Posté par  . Évalué à 1.

                == teste l'égalité. Pour les entiers ça vérifie qu'ils sont égaux (même valeur). Pour les références vers des objets ça vérifie qu'elles sont égales (même valeur). C'est quand même un peu la même chose non ?

                Le bordel c'est de considérer que l'objet Integer doit pouvoir se manipuler comme un entier... Avant la version 1.5 il me semble que le seul "mélange des genres" c'était + qui concatène les String.

                M'enfin entre ceux qui ne veulent pas mélanger et ceux qui veulent pouvoir surcharger le débat me semble sans fin... :)

                (Je dis pas que Java est la 7e merveille du monde hein...)
                • [^] # Re: Comparaison de chaine

                  Posté par  . Évalué à 2.

                  Je comprends parfaitement ce point de vue, mais clairement avec les Integer, on a un comportement particulier, qui n'a d'explication que si on a lu la doc.

                  Ensuite je trouve que == est bien plus visuel que equals, (et j'ai rarement besoin de tester l'égalité de référence (ou même de pointeur en c++); c'est pour ça que trouve que devoir passer par equals est bien lourd.

                  Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: Comparaison de chaine

            Posté par  (site web personnel) . Évalué à 2.

            Merci pour l'exemple, ça continue à m'encourager à éviter autant que possible Java. Quand je pense que ce langage est quand même relativement récent, je ne comprend pas. Qu'on ait des trucs assez horribles en C, je peux comprendre, mais en Java, non. A croire que quand ils l'ont créé ils ne disposaient pas de toutes les recherches qui avaient été faites sur les langages de programmation, des trucs qui sont bien et des trucs à éviter.

            Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

            • [^] # Re: Comparaison de chaine

              Posté par  . Évalué à 2.

              le pire c'est que cette blague est récente 2-3 ans ^^ depuis java 5 en fait (ou java 1.5)

              Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # Résultat des test.

    Posté par  . Évalué à 1.


    public class testMethode {

    //Test sur les methodes imbriquées.

    //Soit une grand méthode

    public static void grandeMethode(){

    //Qui contient une petite méthode

    public static void petiteMethode(){
    System.out.println("Hello World !");
    }

    //appel de la petite Methode
    petiteMethode();
    }

    public static void main(String[] args) {
    //execution
    grandeMethode();

    }
    }


    Pourquoi se code ne marche pas?
    • [^] # Re: Résultat des test.

      Posté par  . Évalué à 2.

      je suis loin d'etre un expert Java, mais
      pourquoi tu veux emboiter des methodes les unes dans les autres ?

      alors que tu peux declarer tes methodes au depart,
      puis les utiliser l'une dans l'autre

      public class testMethode {

      //Test sur les methodes imbriquées.
      //une petite méthode

      public static void petiteMethode(){
      System.out.println("Hello World !");
      }


      //une grand méthode qui appelle la petite methode
      public static void grandeMethode(){

      //appel de la petite Methode
      petiteMethode();
      }

      public static void main(String[] args) {
      //execution
      grandeMethode();

      }
      }
    • [^] # Re: Résultat des test.

      Posté par  (site web personnel) . Évalué à 2.

      >> Pourquoi se code ne marche pas?

      1/ « ce » code.
      2/ si tu dis pas quelle est l'erreur, on ne va pas deviner à ta place.
      3/ « //Test sur les methodes imbriquées. » Au hasard : le test échoue, c'est donc que les méthodes imbriquées ne marchent pas en Java.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.