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 fearan . Évalué à 2.
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 Le Gall Sébastien . Évalué à 1.
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 fearan . Évalué à 2.
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 Le Gall Sébastien . Évalué à 1.
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 Wawet76 (site web personnel) . Évalué à 0.
void maGrosseMethode() {
maPetiteMethodeUn();
maPetiteMethodeDeux();
}
void maPetiteMethodeUn() {
}
void maPetiteMethodeDeux() {
}
}
[^] # Re: argggg
Posté par fearan . Évalué à 1.
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 Le Gall Sébastien . Évalué à 1.
Multiple markers at this line
- Syntax error on token ")", ;
expected
- Syntax error on token "(", ;
expected
...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Comparaison de chaine
Posté par Wawet76 (site web personnel) . Évalué à 2.
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 khivapia . Évalué à 2.
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 Wawet76 (site web personnel) . Évalué à 1.
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 fearan . Évalué à 2.
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 Wawet76 (site web personnel) . Évalué à 2.
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 fearan . Évalué à 2.
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 Wawet76 (site web personnel) . Évalué à 1.
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 fearan . Évalué à 2.
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 lolop (site web personnel) . Évalué à 2.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Comparaison de chaine
Posté par fearan . Évalué à 2.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Résultat des test.
Posté par Le Gall Sébastien . É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 NeoX . Évalué à 2.
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();
}
}
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Résultat des test.
Posté par totof2000 . Évalué à 1.
[^] # Re: Résultat des test.
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
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.