1. Présentation

La définition d’une méthode en Scala se présente comme suit:

[private|protected] [override] def nom [paramètres] [type de retour] [corps]

Ici, ce qui est entre [ ] dénote un élément optionnel.

Notez l’utilisation du mot clé def pour définir une fonction.
Dans Scala, et tout comme pour les définitions des classes, la visibilité par défaut est public, à moins qu’on précise explicitement la visibilité privée (via private) ou protégée (via protected).

Tout comme Java, les fonctions dans Scala sont virtuelles par défaut. Par contre, et à l’inverse de Java, pour redéfinir une méthode virtuelle, il faut le préciser explicitement avec le mot clé override, ce qui permet d’éviter quelques séances intensives de débogage pour comprendre l’origine de bugs bizarroïdes (C’est la même approche que celle prise par C#).

La partie paramètres d’une fonction est un peu différente de celle de Java et ce pour diverses raisons:
– Tout d’abord, à cause de la convention Pascal pour les déclarations (nom:Type)
– Mais aussi le fait que les parenthèses sont complètement optionnelles pour les méthodes sans arguments
– Et enfin, une fonction peut déclarer plusieurs listes de paramètres (j’y reviendrais plus tard)

J’ai déjà montré quelques exemples de méthodes avec les getters et les setters.
En voici une autre:

Cette méthode augmente l’age de la personne de n années.
Son invocation n’a rien d’exceptionnel, et se présente comme suit:

Cette méthode montre entre autres comment le type de retour est optionnel. D’ailleurs, elle ne le déclare pas. La définition exacte aurait été:

2. De l’objet au fonctionnel

Dans cette partie, je vais montrer l’aspect fonctionnel de Scala à travers un exemple où on part d’une implémentation à base des paradigmes de l’OO, puis en convertissant vers une approche plus fonctionnelle.

2.1. La version OO

Il s’agit tout simplement d’implémenter une méthode qui effectue un traitement d’une façon répétitive mais périodique.
Dans l’approche OO (et Java plus précisément), on commencerait par créer une interface qui définit une méthode.
Puis, on créerait une méthode qui prend cette interface comme paramètre ainsi que la période de répétition.

Voici une implémentation de cette approche en Scala :

J’ai défini un trait Action (la chose qui ressemble le plus à une interface dans Scala) avec une méthode doSomething.
J’ai ensuite crée une implémentation PingAction de ce trait qui ne fait qu’afficher le message « ping » dans la sortie standard (j’ai utilisé object au lieu de class tout simplement pour avoir un singelton).
J’ai aussi défini une méthode doPeriodically qui prend un Action et un entier comme paramètres, et qui répète l’exécution de l’action indéfiniment tout en « dormant » à chaque itération.

Voici à titre de comparaison la version Java de ceci:

2.2. La version fonctionnelle

En relisant le code précédent, on constate que malgré le fait qu’on a seulement besoin d’une méthode à exécuter périodiquement, on est obligé de construire plein de plomberie sans réel apport pour pouvoir y arriver, i.e. définir une interface, faire implémenter cette interface par une classe, et passage d’une instance de l’implémentation à la méthode d’exécution.

Or, ceci n’est aucunement nécessaire dans un langage fonctionnel comme Scala, où une méthode est un type de données comme les autres, c’est à dire que l’on peut écrire une méthode qui prend une méthode comme paramètre.

La définition du type d’une méthode en Scala se présente comme suit :

Par exemple, une fonction mathématique comme le sinus ou le consinus admet le type suivant:

(Float) => Float

C’est à dire que c’est une fonction qui prend un float (réel) en paramètre et retourne aussi un réel.

Pour revenir à notre exemple, la méthode doPeriodically a besoin d’une méthode qui ne prend aucun paramètre et qui ne retourne rien, ce qui correspond au type :

() => Unit

Unit en Scala correspond au void de Java.
Voici donc une nouvelle version du programme précédent utilisant ces nouvelles données :

En gros, plus d’interface à implémenter ou d’objets à passer : on passe directement une méthode telle quelle à une autre fonction (via son nom), et celle-ci peut dès lors l’invoquer (toujours via son nom).

3. Concrètement

En fait, la notation « (params) => type-du-résultat » n’est que du sucre syntaxique fourni par Scala pour simplifier l’utilisation des fonctions.
Concrètement, les fonctions sont représentées par un ensemble de traits FunctionN où N dénote le nombre de paramètres qu’elle prend.

Par exemple, le type de fonction ne prenant pas de paramètres est représenté par Function0[+R], où le R dénote le type de retour, tandis qu’une fonction prenant un seul paramètre est représentée par Function1[-T1, +R], où T1 est le type du paramètre et R le type de retour.

Dans tous les cas, ces traits définissent une méthode abstraite apply qui dans le cas de Function1 par exemple est définie comme suit:

apply  (v1 : T1) : R

4. Higher order functions

En utilisant ce qu’on vient de voir, il devient possible de coder des trucs vraiment intéressant avec les fonctions, genre une méthode qui combine deux fonctions en une nouvelle fonction par exemple.
Ce type de fonctions s’appelle fonctions d’ordre supérieur, ou « Higer Order Functions« .
A titre d’exemple, voici une implémentation en Scala de la fonction « rond », dénoté » par « o » en Mathématiques.

Petit rappel : f o g (x) = f(g(x))

Je commence par déclarer un nouveau type MathFunc qui est (Float) => Float, où encore une fonction prenant un float comme paramètre et retournant un float (C’est strictement optionnel, et uniquement dans le but de simplifier le code).

Je code ensuite la fonction rond qui prend deux MathFunc f et g en paramètre et retourne un MathFunc, i.e une nouvelle fonction de type MathFunc et qui devrait correspondre ) f o g.
Comme résultat, cette méthode retourne une nouvelle instance de Function1[Float, Float] dont la méthode apply retourne f(g(x)).

Dans la méthode main, je montre un exemple d’utilisation de cette fonction en combinant deux fonctions f et g que j’ai défini.

Remarque : Veuillez notez que la composition de fonctions que je viens de montrer est déjà implémentée dans Scala par les traits Function*, via la méthode compose.

Maintenant, à titre d’exemple (que je ne vais pas expliquer), et juste pour montrer la puissance de Scala et sa flexibilité, voici un bout de code qui permet de remplacer le « rond(f, g) » de l’exemple précédent par la notation plus naturelle « f o g » (La ligne surlignée en bleu clair):

5. Currying

Cette section a été corrigée suite à une remarque de SpaceGuid. Merci à lui

Le currying est une technique qui consiste à fixer la valeur de quelques uns des paramètres d’une fonction pour en créer une nouvelle qui prend les autres paramètres et qui retourne le résultat de l’originale.

Plus abstraitement, étant donné une fonction de type (X x Y) => Z (prend un paramètre de type X et un autre de type Y, et retourne un résultat de type Z), sa currification la transforme en fonction de type X => (Y => Z), c’est à dire une fonction prenant un paramètre de type X, et retournant une fonction qui prend un paramètre de type Y et retournant un résultat de type Z.

Par exemple, étant donné une fonction mul qui prend 2 paramètres x et y et qui retourne x*y (très intéressante et puissante comme fonction :D), on peut en dériver une fonction double qui prend un seul paramètre x et qui retourne son double (2*x) en fixant la valeur de y à « 2 ».

Le currying est très simple et intuitif à mettre en place avec Scala. Jugez vous en par vous même à travers cet exemple :

En gros, j’ai fait le currying de la fonction mul(x)(y) en fixant la valeur du paramètre x à 2 (via mul(2)), ce qui donne naissance à une nouvelle fonction qui ne prend plus qu’un seul paramètre et qui le multiplie par 2.

6. Exemple: Collections Scala

Les collections de Scala utilisent intensivement l’aspect fonctionnel du langage, ce qui permet de réaliser des traitements complexes sur une liste d’une façon intuitive et fluide.

Je vais commencer par montrer quelques exemple simples, pour finir avec d’autres plus complexes.

6.1. Exemples simples

Les commentaires expliquent ce que fait chaque méthode.
Notez que j’ai usé du type-inference du compilateur Scala pour pouvoir écrire

(x, y) => x + y

par exemple en omettant les types des arguments :

6.2. Ne joues pas au plus « Perl » avec Scala !

Maintenant, je vais présenter les même exemples de la section précédente, mais en introduisant la « Perl touch », i.e. quelques hiéroglyphes magiques qui réduisent considérablement la taille de code (mais au risque de réduire autant la lisibilité du code).
L’hiéroglyphe magique en question dans Scala est le « _ », qui représente le joker (% dans le SQL, ? dans les expressions régulières, * dans les noms de fichiers, etc.).
Il a plusieurs connotations dans Scala et ce selon où il est utilisé.
Dans le cas des closures, il permet de représenter un paramètre d’une fonction.
Par exemple, « (x) => 2 * x » peut être ré-écrit en « 2 * _« , et le compilateur Scala est assez malin pour savoir ce qui va dans le slot « _ ». De même, le compilateur peut se débrouiller avec un truc comme « _ + _ » qui correspond à « (x, y)=> x + y » peut devenir .
Ainsi, le code précédant devient :

6.3. Exemple plus complexe

No comment ! en fait si, un commentaire : dans Scala, ça bloque pas, c’est très fluide

Conclusion

Voilà, ainsi s’entame le troisième volet de l’introduction à Scala qui a servi, je l’espère, à présenter l’aspect fonctionnel de Scala via le.
Dans le prochain volet, ce serait le tour des traits, une sorte d’interfaces Java aux stéroïdes.

1. Présentation

La définition d’un trait en Scala se présente comme suit:

Ici, ce qui est entre [ ] dénote un élément optionnel, le | indique que l’une ou l’autre des alternative est applicable, et … indique que ce qui précède peut être répété à volonté.

Bref, le plus important c’est le mot clé « trait« , qui la différencie d’une classe ordinaire.

Voici un exemple d’un trait:

Ici, j’ai défini un trait nommé Action qui contient une seule méthode abstraite action.

Voici maintenant une classe qui étend ce trait :

Veuillez noter qu’une classe peut étendre plusieurs traits, et ce en utilisant le mot clé with à partir du second tait étendu, comme montré dans l’exemple suivant:

2. Les traits comme des interfaces

Dans une première approche, on peut utiliser les traits de Scala pour émuler les interfaces de Java, en limitant leur rôle à la définition des contrats des classes.

A titre d’exemple, considérons ce bout de code :

J’ai commencé par définir un trait Age pour représenter une entité ayant un âge, d’où la méthode abstraite age.
J’ai ensuite défini un trait Comparable qui contient quelques méthodes permettant de comparer deux entités ayant un âge comme sameAge, olderThan, etc.

A la fin, j’ai implémenté ces deux traits dans une classe Person.

3. Les traits pour simplifier l’implémentation

La tache des classes implémentant le trait Comparable peut être grandement simplifié quand on sait que plusieurs méthodes du trait Comparable peuvent être déduites de deux autres méthodes de ce même trait.
Par exemple, si on suppose disposer de sameAge et olderThan, on peut donc déduire le reste des méthodes :
– youngerThan est alors !olderThan(that) && !sameAge(that)
– etc.

Les traits Scala, et à l’inverse des interfaces de Java, peuvent avoir des champs et implémenter des méthodes.
En tirant profit des deux points précédents, on peut ré-écrire l’exemple précédent en :

Ainsi, il suffit d’implémenter 2 méthodes des 5 définies par Comparable pour avoir une implémentation complète.

4. Utiliser les traits comme décorateurs

Un autre utilisation possible des itérateurs serait des les combiner à une classe donnée en tant que décorateurs, apportant de nouvelles fonctionnalités ou modifiant les fonctionnalités existantes.

Pour illustrer ce concept, commençons par définir un trait représentant une opération quelconque :

Ainsi qu’une implémentation bidon, qui lance ou non, et de façon aléatoire une exception :

Je vais commencer par un décorateur simple, qui ne fait qu’afficher un message avant l’exécution de l’action concrète et un autre après sa fin.
Un tel décorateur se définit comme un trait ordinaire, avec quelques points à respecter :
– Il doit hériter du trait définissant l’action (Action)
– Il doit implémenter la méthode du trait parent, tout en déclarant cette implémentation comme abstraite, pour s’assurer que la classe d’implémentation concrète définisse bel et bien l’action réelle.
– L’implémentation réelle de l’action peut alors être référencée par super.action() dans le trait de décoration.

En suivant ces règles, le trait de logging s’écrit alors :

Maintenant, pour combiner ce décorateur à l’action concrète, on procède comme suit :

Notez l’instanciation de l’action concrète suivie du mot clé with et du nom de du trait décorateur.

A l’exécution, on obtient :

On peut dès lors imaginer toute sorte de décorateurs, comme par exemple un décorateur qui répète N fois l’action tant qu’elle lance une exception :

Ou encore un décorateur qui rend l’exécution synchronisée :

Enfin, on peut associer une classe donnée à plusieurs traits de décoration comme suit :

Notez que l’ordre de l’apparence d’un trait dans l’instanciation influe sur son ordre à l’exécution : le premier trait qui apparaît serait le dernier à être exécuté, et ainsi de suite.
Dans tous les cas de figure, la classe concrète serait exécutée en dernier.

Ainsi, dans l’exemple précédent, l’ordre d’exécution serait :

Conclusion

Dans ce volet de l’introduction à Scala, j’ai présenté les traits via quelques cas d’utilisations courants.
N’hésitez surtout pas à me communiquer vos impressions, critiques et propositions et ce en commentant dans ce même blog, ou via messages privés (via forum).

Comme il se doit dans de telles occasions, je vais commencer par l’inévitable Hello World, ou plus précisément comment récupérer ce qu’il faut pour faire du Scala et comment écrire, compiler et exécuter son premier programme.

Je vais commencer par les outils.
Malheureusement, Scala ne dispose pas encore de tooling décent, mais ça viendra, je n’en doutes pas.

En gros, vous avez le choix entre la méthode dure ou encore la méthode moins dure.

La méthode dure: ça consiste à télécharger la distribution Scala (la dernière version est la 2.7.0):

• Version Linux (tar.gz: 12.2Mo, tar.bz2: 11.8Mo)
• Version Windows (Zip: 13.6Mo)

Il faut ensuite extraire l’archive téléchargé quelque part dans son disque (${SCALA_HOME}), et ajouter le dossier ${SCALA_HOME}/bin dans le PATH.

La méthode moins dure: ça consiste à passer par le plugin eclipse officiel de Scala.
Faites pointer un nouveau Update site (Remote) sur cette adresse:

http://www.scala-lang.org/downloads/scala-plugin/

N.B. Ce plugin nécessite eclipse 3.3.* et une JRE >= 5.0

Une fois le plugin installé et eclipse redémarré, vous disposerez d’un support décent de Scala mais pas plus.

Le plugin offre:
– Menu New:

– Coloration Syntaxique

– Emplacement des erreurs mais pas leur messages (ne me demandez pas pourquoi)

– Menu d’exécution et de débogage (qui marche parfois )

– Voilou.

C’est encore très loin d’un tooling du calibre du JDT, mais c’est déjà infiniment plus pratique que de passer par le compilateur en ligne de commande.

Une fois votre environnement mis en place et configuré, il faudrait créer un fichier HelloWorld.scala avec le code suivant

Si vous êtes sous eclipse avec le plugin Scala, il suffit de passer par le menu Run, Run As, Scala Application.
En ligne de commande, il faudrait taper les commandes suivantes:

>cd "l'emplacement du fichier" 

>scalac HelloWorld.scala 

>scala HelloWorld

Je vous laisse deviner la sortie de ce programme

Passons maintenant à l’analyse de ce bout de code:

object HelloWorld {
Il s’agit ici de la déclaration d’un objet nommé HelloWorld.
Dans la terminologie Scala, un objet est grosso modo l’équivalent d’une classe Java complètement statique. Mais en réalité, Scala ne supporte pas la notion des membres statiques et propose plutôt les objets qui sont des singletons.
Si on a besoin d’un membre statique, il faut le déclarer dans un objet.

def main(args: Array[String]) {
Il s’agit ici de définir la méthode main de l’objet, i.e. la méthode où commence l’exécution du programme.
Une méthode est déclarée avec le mot clé def en Scala suivi par son nom, ses paramètres et son type de retour.
Comme je viens de le préciser, et à l’inverse de Java, la méthode main n’est pas statique (Scala n’a pas de notion de membres statiques), mais fait partie d’un objet (singleton).

Les paramètres de cette méthode sont toujours précisés entre parenthèses.
Là, un point capital dans Scala, les déclaration des variables est similaire à ce qu’on fait dans Pascal, c’est à dire de la forme « nom_de_la_variable : type_de_la_variable » et non pas comme dans les langages EcmaScript-like (C, C++, Java, JavaScript, etc.) où l’on procède plutôt par: « type_de_la_variable nom_de_la_variable »

Comme pour Java, main prend un tableau de chaînes, représenté dans Scala par Array[String].
Je tiens tout d’abord à préciser que les crochets ici n’ont rien à voir avec les tableaux, et qu’il servent plutôt à déclarer les paramètres génériques d’un type (équivalent aux < et > de Java).

de plus, Scala est un langage orienté objet pur, dans la mesure où tout est soit un objet, soit un passage de message (appel de méthode) entre objets.
Donc exit les types primitifs (int, char, etc.) ou les types spéciaux (tableaux, etc.)
Ici, Array est un objet ordinaire et à part entière tout comme les listes par exemples.

Un autre point important à signaler ici est que malgré le côté objet pur de Scala, qui est une idée noble en théorie, mais généralement associée à de graves problèmes de performance en pratique, Scala transforme les objets aux types primitifs lors de la compilation là où c’est possible, ce qui élimine complètement les problèmes de performances.

val message = « Hello World »
Il s’agit ici d’une déclaration de variable, ou plus exactement d’une constante.
La déclaration commence par le mot clé val qui est l’équivalent du final de Java. On aurait pu aussi utiliser var au lieu de val pour ôter l’aspect constant de la variable.

S’en suit le nom de la variable, message ici, puis l’initialisation avec le littéral « Hello World ».

La question qui se pose est où est le type de la variable ?
Scala est un langage statiquement typé, et chaque membre doit obligatoirement avoir un type. Seulement, le compilateur de Scala est suffisamment intelligent pour reconnaître automatiquement le type d’un membre donné pour faire éviter au programmeur d’avoir à le spécifier explicitement tout le temps: c’est l’inférence de types.

Attention toutefois: ce n’est pas toujours possible d’avoir une inférence automatique, et il y’a des cas où l’on devrait spécifier explicitement le type de déclaration.

Dans ce cas-ci, vu que la partie droite de l’assignation est un littéral de type String, Scala infère automatiquement String comme type de message.

Si on voulait plutôt s’exercer à l’art de pourquoi-taper-moins-qunad-on-peut-taper-plus, on aurait pu déclarer explicitement le type ainsi:

val message : String = « Hello World »

Seulement, quand est ce qu’on sait si l’inférence de types est possible et quand est ce que ça ne l’est pas ?
Difficile de répondre … le moteur d’inférence de types de Scala est complexe, et il ne cesse d’évoluer au fil des versions.
En règle générale, essayez de ne pas déclarer les types jusqu’à ce que le compilateur s’en plaint

Avant de passer à l’instruction suivante, vous l’aurez remarqué peut être déjà: les « ; » sont optionnels dans Scala, dans la mesure où l’on met une instruction par ligne, ce qui est, j’espère, le cas tout le temps.
(Ce n’est pas la seule condition pour ne pas mettre des ; en fin de ligne en fait)

println(message)
L’instruction suivante est claire: ça affiche la valeur de message dans la console.
Notez juste le println introduit par Scala au lieu du system.out.println. Toutefois, il est toujours possible d’utiliser ce dernier si vous êtes adeptes de la règle citée plus haut :), chose possible grâce au fait que Scala importe implicitement tout le package java.lang mais aussi la compatibilité de Scala avec Java:

• On peut utiliser les objets Java dans Scala
• On peut étendre des classes Java dans Scala
• On peut implémenter des interfaces Java avec Scala
• Un programme Scala compilé tourne sur la JVM

L’autre sens n’est pas vrai.

Ainsi s’achève ce premier billet de la série « Introduction à Scala », dans lequel j’ai présenté quelques notions (surfaciques) sur le langage de programmation Scala.

1. Classes

1.1. Définition d’une Classe

Je vais commencer par les classes. Scala ne joue pas aux fantaisies ici, et une classe est toujours une structure regroupant champs et traitements.

Voici la déclaration minimale d’une classe en Scala

A l’inverse de Java, une classe est par défaut publique, donc plus besoin d’ajouter public à la déclaration.
D’ailleurs, le mot public n’existe même pas pour Scala.
Là, on peut se poser la question de ou est passé le modificateur de visibilité par défaut de Java, qui limite l’accès à un champ/classe au package dans lequel il/elle est défini ?
Scala va beaucoup plus loin (encore une fois) que Java en offrant un contrôle très précis de qui a le droit d’accéder à tel ou tel champ/classe, mais ce n’est pas dans le cadre de ce billet.

1.2. Définition des champs

Ajoutons maintenant quelques champs à cette classe, ce qui donne:

La déclaration d’un champ se présente comme suit:

[modificateur de visibilité] (var|val) nom [:Type] [= Valeur]

les parties entre [ et ] sont optionnelles, et (x|y) indique un choix exclusif entre deux options x et y.
var indique qu’un champ est muable tandis que val indique qu’un champ est immuable.

Une note importante s’impose: si un champ n’est pas initialisé avec une valeur lors de sa déclaration, il est considéré par Scala comme champ abstrait.

Vous êtes déjà habitués aux méthodes et classes abstraites dans Java. Scala va encore plus loin en étendant cette notion au champs aussi.

Ainsi, il est nécessaire d’assigner une valeur à un champ lors de sa déclaration si on ne veut pas qu’il soit considéré comme abstrait.

Dans le cas où on n’a pas de valeur précise à assigner comme valeur par défaut à un champ, on peut utiliser le ‘wild card‘ _ de Scala comme valeur, comme ici:

Le ‘_’ serait traduit par le compilateur en la valeur adapté au type du champ, 0 pour les Int, «  » pour les chaînes, etc.

Optimisons encore la chose en tirant profit du puissant système d’inférence de types de Scala, qui nous permet de ne pas avoir à declarer le type d’un champ du moment que ce même type peut être déterminé depuis la valeur d’initialisation:

Tout comme pour les classes, les champs dans Scala sont publics par défaut.

Voici maintenant comment on peut instancier une telle classe et l’utiliser:

Là, je vois déjà les puristes OO en désarroi face à cette absence d’encapsulation: accès direct aux champs ?? !!

Rassurez vous, même si ça en a tout l’air, ‘under the hoods‘, Scala alloue un espace mémoire pour un champ inaccessible au programmeur, et génère automatiquement l’équivalent d’un getter et d’un setter Java et ce sont eux qui sont invoqués lors de la lecture et écriture (plus de détails dans la suite).

1.3. Constructeurs

a. Constructeur principal

Je vais maintenant montrer une autre fonctionnalité puissante de Scala qui s’adapte bien à ce genre d’objets (conteneurs de données): les constructeurs.

Les constructeurs d’une classe dans Scala sont un peu différents de ceux en Java, et sont considérés des ‘first class citizens‘.

Voici comment on définit le constructeur principal d’une classe Scala:

Yep, la classe tient désormais sur une seule ligne
Ce bout de code définit à la fois les deux champs name et age ainsi qu’un constructeur qui prend les valeurs de ces deux champs comme paramètres.

Voici comment instancier une telle classe:

Qui comme vous le remarquez est similaire à ce qu’on fait en Java.

b. Constructeurs auxiliaires

Maintenant, la question qui se pose, est comment déclarer, tout comme dans Java, d’autre constructeurs de signatures différentes ?
C’est tout à fait logique vu comment est défini le constructeur principal.

Scala impose la limite suivante: on peut définir d’autres constructeurs, mais ils doivent obligatoirement invoquer directement ou indirectement le constructeur principal.

Voici comment déclarer d’autres constructeurs (secondaires ou auxiliaires):

Et voici comment invoquer ces nouveaux constructeurs

Les constructeurs secondaires peuvent très bien effectuer d’autres traitements, comme dans ce cas par exemple:

Mais la règle d’invocation du constructeur principal tient toujours. Ici, ça se fait indirectement.

1.4. Getters et Setters

La question suivante est comment spécifier par exemple son propre getter et setter pour un champ ainsi défini ?

Voici comment ça se fait:

J’ai d’abord ajouté private à la déclaration de age dans le constructeur (en le renommant en a du même coup) et défini deux méthodes (via le mot clé def):

• age: qui ne fait que retourner le champ privé a en lui ajoutant la chaine  » ans », d’où le type de retour en String. Remarque que j’aurais pu retourner a directement et mettre le type en Int, c’est juste pour montrer les possibilités …
• age_= : oui, ‘age_=’ est un identificateur valide en Scala. Cette méthode prend un paramètre de type Int, et teste s’il est positif, auquel cas elle affecte sa valeur au champ a, autrement elle lance une exception.

Voici maintenant un bout de code qui teste ce qu’on a fait:

p.age qui est passé à println invoque bel et bien le getter qu’on a défini, et retourne « 25 ans ».
p.age = 15 invoque le setter et ça passe, vu que 15 > 0
p.age = -5 lance une exception, comme prévu

2. Objets

2.1. Définition

Passons maintenant aux objets.
Les objets sont une notion spécifique à Scala (par rapport à Java) et se présentent entre autres comme remplaçant du contexte static de Java (inexistant dans Scala).
Dans la section précédente, j’ai montré comment définir une classe (une partie du moins).
Une classe ne définit que la structure de l’entité, mais pour l’utiliser, il faut l’instancier dans un conteneur pour pouvoir la manipuler.

Un objet est tout comme une classe dans la mesure où il définit la structure, mais il définit aussi l’instance, ce qui permet de le manipuler directement, sans avoir à l’instancier dans un conteneur.

Seulement, dans Scala, il s’agit plutôt d’un Singleton, crée, et maintenu par le compilateur.
Un objet est crée la première fois qu’on y accède, et c’est cette même et unique instance qui sera partagée entre tous ses clients.

2.2. Exemples

a. La méthode main

L’exemple le plus courant de l’utilisation des objets dans Scala est tout comme Java, pour définir la fonction main, le point d’entrée d’un programme.
Une telle méthode doit obligatoirement être définie dans un Objet, comme dans le montre cet exemple:

La déclaration d’un objet utilise object au lieu de class.

b. Le cas général

Voici un autre exemple où l’on définit une méthode utilitaire (square) pour pouvoir l’invoquer sans avoir à instantier une classe (comme Math de Java):

On peut dès lors accéder directement à la méthode square:

Pour tout le reste, les objets et les classes dans Scala se présentent de la même façon, excepté l’absence de constructeurs, qui n’ont plus aucun sens dans un objet.

3. Conclusion

Voilou, c’est la fin de ce (long) billet, qui a présenté quelques notions de base sur la définition et l’utilisation des classes et des objets dans Scala.
Le billet suivant de la série « Introduction à Scala » couvrirait les méthodes et les fonctions, qui sont des entités à part entière dans Scala et permettent de faire des choses très intéressantes …

Changelog

=> 11/07/08: J’ai corrigé la partie sur les constructeurs suite à un retour de gorgonite (à propos du currying). Merci à lui.