Variables et accès en Java

Déclaration des variables final transient static private Printer hp; transient => ne doivent pas être sérialisées volatile => pour empêcher le compilateur de faire certaines optimisations (registre) Exemple d’usage « User variables that are referenced by multiple threads should have the attribute volatile to ensure that all changes to the value of the variable are performed immediately by the compiler. » to ensure that the variable is loaded from memory before each use, and stored to memory after each use to ensure that the value of the variable is consistent and coherent within each thread

Contrôle de l’accès aux variables Par défaut

Variables de classe Une variable de classe est créée une seule fois. La même variable de classe est partagée par toutes les instances de cette classe Les variables de classes peuvent être accédées via les instances et via les classes Les méthodes d’instance peuvent accéder aux variables de classes Les méthodes de classe NE peuvent PAS accéder aux variables d’instance class AnIntegerNamedX { static int x; public int x() { return x; } public void setX(int newX) { x = newX; } }

Initialisation directe des variables class BedAndBreakfast { static final int MAX_CAPACITY=10; boolean full = false; }

Initialisation des variables: bloc “static” Une classe peut avoir autant de bloc d’initialisation qu’elle le désire Ces blocs peuvent apparaitre n’importe où dans le corps de la classe. A l’exécution, le système garantit que ces blocs statiques d’initialisation et les initialisation statiques seront appelées dans leur ordre d’apparition dans le code source, i.e. de gauche à droite et de haut en bas).

Initialisation dans les constructeurs class Rectangle { Rectangle() { this(0,0,0,0); } Rectangle(int width, int height) { this(0,0,width,height); } Rectangle(int x, int y, int width, int height) { this.x = x; this.y = y; this.width = width; this.height = height ; } La meilleure approche Tout le code d’initialisation se trouve à un seul endroit Code plus facile à lire Code plus facile à maintenir. Les valeurs par défaut sont manipulées explicitement.

Portée des variables

Les packages Comme mécanisme d’encapsulation Fournit une façon de partager de l’information à l’intérieur du package tout en empêchant son usage à l’extérieur Seuls les classes et interfaces déclarés public peuvent être utilisés par le code situé à l’extérieur du package Comme mécanisme de nommage Un package possède un nom hiérarchique qui permet de le distinguer des autres packages Les classes et les interfaces ont des noms relatifs à leur package Les définitions des autres packages peuvent être utilisés à l’aide de leur nom complètement qualifié Il peut y avoir conflit entre ces deux rôles Il peut être pratique de grouper plusieurs définitions dans le même package parce que le code externe aura accès à toutes ces classes en important un seul package Cette approche est souvent mal fondée du point de vue de l’encapsulation parce que le code d’un package a souvent accès à de l’information interne des autres définitions du package Morale: résoudre ce conflit en faveur de l’encapsulation

Déclaration des classes

Par défaut

Constructeur Si aucun constructeur n’est déclaré, par défaut, le système fournit un constructeur vide qui ne fait rien

Héritage des variables et des méthodes Une sous-classe hérite de tous les membres de sa superclasse qui sont accessibles à cette sous-classe à moins que la sous-classe ne cache explicitement une variable la sous-classe ne redéfinisse une méthode. Les constructeurs ne sont pas des variables ou des méthodes par conséquent ils ne sont pas hérités par les sous-classes.

Héritage des variables et des méthodes Les sous-classes héritent des membres (variables et méthodes) déclarés public ou protected. Les sous-classes héritent des membres des superclasses déclarés sans spécification d’accès en autant que la sous-classe se trouve dans le même package que les superclasses. Les sous-classes n’héritent pas des membres de la superclasse si la sous-classe déclare un membre avec le même nom. Dans le cas d’une variable, la variable de la sous-classe cache celle de la superclasse. Dans le cas d’une méthode, la méthode de la sous-classe redéfinit celle de la superclasse

Conversion, surcharge et redéfinition Vérification de typage utilise toujours le type apparent cast (nom d’une classe) expression Conversion implicite des valeurs d’un type en un autre Seulement pour les types primitifs Ordre croissant de généralité byte -> short -> int -> long -> float -> double –i = l illegal –l = i legal int = charlegal char = intillegal

Surcharge Plusieurs méthodes qui partagent le même nom Les méthodes sont différenciées par le nombre et le type des paramètres La méthode la plus spécifique est invoquée Une méthode m1 est plus spécifique qu’une méthode m2 si toute invocation légale de m1 serait aussi une invocation légale de m2 si d’autres conversions seraient effectuées S’il n’existe pas de méthode plus spécifique, alors erreur de compilation Tient compte des conversions implicites et des relations d’héritage

Redéfinition Une classe peut redéfinir une méthode de sa superclasse. Cette méthode doit avoir le même nom, le même type de résultat la même liste de paramètres. On ne peut pas redéfinir une méthode déclarée final On doit redéfinir une méthode déclarée abstract

Sécurité du typage Java garantit la sécurité du typage (type safety) Un langage fortement typé Les erreurs de typage sont détectés par le compilateur Gestion automatique de l’espace-mémoire Ramasse-miettes Vérification de tous les accès aux vecteurs pour s’assurer qu’ils en respectent les bornes. Une différence importante entre Java et C++