Partage
  • Partager sur Facebook
  • Partager sur Twitter

Questions de reconverti

Sujet résolu
27 avril 2012 à 18:42:18

Bonjour,

D'avance désolé si je pose des questions déjà résolues précédemment, mais je n'ai pas trouvé mon bonheur avec le moteur de recherche du SdZ.

Voilà je commence Java et je fais la comparaison avec Python et C++ car c'est là d'où je viens. Donc pour être certain :

-> Aucune surcharge d'opérateurs (+, ==, etc.) n'est possible en Java
-> Les paramètres facultatifs de méthodes sont impossible, par exemple :

public static void sansTitre(int a, int b = 0) {
    System.out.println(a+b);
}


ne fonctionne pas, et il faut en passer par la surcharge de méthodes :


public static void sansTitre(int a, int b) {
    System.out.println(a+b);
}
public static void sansTitre(int a) {
    sansTitre(a, 0);
}


Est-ce cela ? est-ce irrévocable ?

EDIT : l'ordre des "étiquettes" (public, static, final, void, etc) devant les classes, les méthodes, les champs, est-il important ? si oui quelles sont les règles à respecter ?

EDIT2 : est-il standard de mettre une seule classe par fichier, ou bien laisser plusieurs classes dans un même fichier est en pratique couramment réalisé par les programmeurs expérimentés ?

EDIT3 (décidément j'en ai des questions...) : dans le tuto du C++ il était recommandé pour plus d'aisance de mettre tous les attributs de classe en mode protected, pour que les classes dérivées aient facilement accès aux attributs dont ils ont hérités. Mais dans un bouquin de Java ils conseillent d'éviter au maximum le modificateur de visibilité "protected" pour éviter que des sous classes dérivées se retrouvent gênés si la classe primitive est modifiée.
Qu'en pensez-vous ?

Merci, d'avance ! bon WE à tous les zéros !

icelake
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
27 avril 2012 à 19:59:03

pas de surchage d'opérateur, obligé de passer par la surchage oui.

on peut en permutter certains (static et final par exemple) mais la norme est public static final void nom()

une classe par fichier avec des inner class si nécessaire.

protected pour les attributs, c'est mal.
  • Partager sur Facebook
  • Partager sur Twitter
27 avril 2012 à 20:03:38

Je vais essayer de répondre (il se peut que je me trompe sur certaines choses) :
  • Aucune surcharge d'opérateurs (+, ==, etc.) n'est possible en Java
    En effet, pas de surcharge des opérateurs. Java est un peu étrange en utilisant un modèle qui n'est pas totalement objet et les éléments qui sortent de ce modèle ne peuvent pas être modifié.
  • Les paramètres facultatifs de méthodes sont impossible
    Pas de paramètre facultatif. Il y a cependant la notation "varargs" qui permet de récupérer des éléments de même type dans un tableau.
  • Est-ce irrévocable ?
    Si vous cherchez un langage dynamique non typé fonctionnant sur la JVM, je vous invite à regarder du côté de Groovy qui permet de faire tout cela tout en ayant accès à toutes les librairies java.
    Mais l'objectif n'est pas le même, moins de contraintes plus de bugs potentiels et plus difficile à trouver, surtout sur une grosse appli.
  • l'ordre des "étiquettes" (public, static, final, void, etc) devant les classes, les méthodes, les champs, est-il important ? si oui quelles sont les règles à respecter ?
    Pour être propre oui, je pense qu'il y a un standard qui définit ça. Tout bonne Ide devrait mettre un warning si l'ordre n'est pas bien respecté.
    Cet ordre est :
    public static final int x;
    

  • Est-il standard de mettre une seule classe par fichier, ou bien laisser plusieurs classes dans un même fichier est en pratique couramment réalisé par les programmeurs expérimentés ?
    Il faut considérer qu'il faut mettre une seule classe par fichier. Comme toute règle il y a des exceptions, quand une classe n'est utilisée et visible que depuis une autre classe ou qu'elle représente un type qui est vraiment rattaché à celle-ci (Map.Entry), les types enums ...
    Mais bon il faut mieux partir du principe une classe = un fichier.
  • il était recommandé pour plus d'aisance de mettre tous les attributs de classe en mode protected, pour que les classes dérivées aient facilement accès aux attributs dont ils ont hérités. Mais dans un bouquin de Java ils conseillent d'éviter au maximum le modificateur de visibilité "protected" pour éviter que des sous classes dérivées se retrouvent gênés si la classe primitive est modifiée.
    Tout dépends de ce que l'on veut faire. Chaque cas est différent mais je serais plutôt pour mettre private par défaut et le changer si besoin (mais si votre classe est réutilisée depuis un autre projet sans que l'on puisse la modifier ça peut limiter ce que l'on peut faire). On peut aussi avoir des attributs private avec des accesseurs protected.
  • Partager sur Facebook
  • Partager sur Twitter
27 avril 2012 à 21:06:06

Merci pour toutes ces réponses ! Dernière petite question : si l'on sépare du code dans un bloc entre accolades sans que ce soit une boucle, une condition, une classe, ou une méthode, simplement pour que le code soit plus lisible, cela affectera-t-il l'exécution du code ?

Merci encore ! :D
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
27 avril 2012 à 21:09:20

non, ça réduit juste la portée de ce qui est dedans.
  • Partager sur Facebook
  • Partager sur Twitter
27 avril 2012 à 21:15:21

ok merci encore, et bon WE à tous ! :p
  • Partager sur Facebook
  • Partager sur Twitter