Apprendre la programmation orientée objet par la pratique

Vous souhaitez apprendre à développer des applications informatiques ? Vous souhaitez développer des applications de données ? Alors vous devez impérativement apprendre la programmation orientée objet.

Pour développer applications de traitement de données performantes (que ce soit des applications de base de données, des middleware, des applications de reporting, etc…), vous avez besoin d’une boîte à outils plus fournie que celle offerte par la programmation informatique classique ou la programmation fonctionnelle, car lorsqu’on veut développer des applications qui combinent les exigences d’un processus métier particulier aux contraintes technologiques du traitement de données, on a besoin de concepts, d’outils et de méthodologies qui n’existent que dans le paradigme orienté objet.

Dans cet article, vous allez apprendre la programmation orientée objet, notamment vous apprendrez à utiliser ses concepts, ses méthodes et sa boîte à outils dans vos propres applications. Considérez cette article comme un guide complet sur la programmation orientée objet.

1 – Définition et origine du paradigme orienté objet

La programmation orientée objet (POO) est un modèle de programmation informatique qui met en œuvre une conception basée sur les objets. Elle se différencie de la programmation procédurale, qui est basée sur l’utilisation de procédures, et de la programmation fonctionnelle, qui elle, repose entièrement sur le concept de fonction.

Les premiers concepts de la programmation orientée objet remontent aux années 1970 avec les les langages Simula et Smalltalk.

Au cours des années 1980,  commence l’effervescence des langages à objets : Eiffel, C++, ou encore Objective C (une extension objet du C utilisé par l’iOS d’Apple). Cette effervescence atteint son apogée dans les années 1990 avec l’extension de la programmation par objets dans les différents secteurs du développement logiciel et la création du langage Java par la société Sun Microsystems (racheté depuis par Oracle).

Le succès de Java, plus simple à utiliser que ses prédécesseurs, est tel que Microsoft décide au début des années 2000 de sortir son propre framework, le .NET et son propre langage full orienté objet, C#, pour éviter de voir le marché de l’OS PC l’échapper au profit de l’écosystème open source, porté désormais par Java.

La Programmation orientée objet devient alors un paradigme incontournable à tout informaticien et à tout développeur d’application qui se respecte.

De nos jours, de très nombreux langages permettent d’utiliser les principes de la POO dans des domaines variés : Java et C# bien sûr, mais aussi PHP (à partir de la version 5), Python, etc… La Programmation orientée objet a entraînée un changement profond dans la manière de  concevoir l’architecture des applications informatiques.  Au cours de la modélisation d’une application on réfléchit désormais en termes d’objets : c’est la modélisation orientée objet (MOO), dont le principal support est le langage de modélisation UML.

Dans cette chronique nous verrons ensemble les concepts clés de la programmation orienté objet, et dans la suite, nous essayerons de montrer avec des exemples précis l’implémentation de ces concepts en JAVA.

2 – Les langages orientés objet

Comme nous l’avons mentionné plus haut, l’effervescence des langages objet commence en 1980 et atteint son paroxysme dans les années 1990. Avant d’entrer dans les caractéristiques de ces langages, il est bon de rappeler les principaux avantages du paradigme orienté objet :

• La modularité :  les objets forment des modules compacts regroupant des données et un ensemble d’opérations.
• L’abstraction : les objets de la POO sont proches de celles du monde réel. Les concepts utilisés sont donc proches des abstractions familières que nous exploitons.
• Productivité et ré-utilisabilité : plus l’application est complexe et plus l’approche POO est intéressante. Le niveau de ré-utilisabilité est supérieur à la programmation procédurale.
• Sûreté : l’encapsulation et le typage des classes offrent une certaine robustesse aux applications.

Revenons maintenant sur les langages objet proprement dit. Simula (1967)  est généralement reconnu comme étant le premier langage orienté objet. Il a été créé pour réaliser des programmes de simulation. Smalltalk (1972 à 1980) est un autre exemple précoce, et celui avec lequel une grande partie de la théorie de la POO a été développée.

On distingue plusieurs catégories de langage orienté objet, tout dépend du degré d’utilisation des objets et du niveau d’intégration du langage au paradigme orienté objet :

•  Les langages dits de POO « purs », où tout est traité comme un objet, depuis les primitives telles que les caractères et la ponctuation, jusqu’aux classes, prototypes, blocs, modules. Ils ont été conçus spécifiquement pour faciliter, voire imposer, les méthodes orientés objet.  Ex: Ruby, Scala, Smalltalk, Eiffel, Emerald, JADE, Self, Raku.

•  Les langages conçus principalement pour la programmation OO, mais avec quelques éléments procéduraux. Ex : Java, Python, C++, C#, Delphi/Object Pascal, VB.NET.

• Les langages qui sont historiquement des langages procéduraux, mais qui ont été étendus avec certaines caractéristiques orientées objets. Ex : PHP, Perl, Visual Basic (dérivé de BASIC), MATLAB, C++, C#, COBOL 2002, Fortran 2003, ABAP, Ada 95, Pascal.

• Les langages possédant la plupart des caractéristiques des objets (classes, méthodes, héritage), mais sous une forme nettement originale. Ex: Oberon (Oberon-1 ou Oberon-2).

• Les langages avec support de types de données abstraits qui peuvent être utilisés pour ressembler à la programmation OO, mais sans toutes les caractéristiques de l’orienté  objet Ex : JavaScript, Lua, Modula-2, CLU.

Ces dernières années, la programmation orientée objet est devenue particulièrement populaire dans les langages de programmation dynamiques. Python, PowerShell, Ruby et Groovy sont des langages dynamiques construits sur les principes de la POO, tandis que Perl et PHP ont ajouté des fonctionnalités orientées objet depuis Perl 5 et PHP 4, et ColdFusion depuis la version 6.

Quoique aujourd’hui, il foisonne des langages orientés objet dans le marché, celui-ci est principalement dominé par le langage Java. Ainsi, lorsqu’on parle orienté objet à ce jour, on pense à Java. Nous développerons la programmation Java dans une autre chronique.

3 – Les concepts fondamentaux de la programmation orientée objet

La programmation orientée objet repose sur 5 concepts fondamentaux à savoir :

• La classe
• L’objet
• L’encapsulation
• L’héritage
• Le polymorphisme

Nous allons voir distinctement chacun de ces concepts.

Le concept de Classe

Le premier concept fondamental de l’orienté objet est la classe. Une classe est une structure abstraite qui décrit des objets du monde réel sous deux angles : ses propriétés (ses caractéristiques) et ses méthodes (les actions qu’elle peut effectuer ou son comportement).

Par exemple, la Classe Vehicule représente un véhicule, couleur est l’une de ses propriétés et accélérer/freiner sont deux de ses méthodes. Un autre exemple : on peut représenter en programmation orientée-objet les employés sous forme de classe ; auquel cas, la classe Employés représente tous les employés qui peuvent avoir pour propriétés un nom, un prénom, une adresse et une date de naissance ; les opérations qui peuvent être effectuées  sur les employés peuvent être le changement de salaire, la prise de congé, la prise de retraite, etc.

La classe est finalement une sorte de moule, de modèle. Toutes les instances de classe s’appellent des objets. Les objets sont construits à partir de la classe, par un processus appelé instanciation. De ce fait, tout objet est une instance de classe.

Dans notre exemple ci-dessus couleur, poids et prix sont les attributs de classe Voiture et demarrer(), accelerer() sont ses méthodes.

L’instanciation d’une classe fait appel à 3 méthodes spéciales dont la compréhension est très importante :

• Le constructeur :  on distingue trois types de constructeurs

1. Le constructeur par défaut appelé par défaut lors de la création d’un objet (offert par défaut lors de la compilation s’il n’y a pas de constructeur déclaré),
2. Le constructeur par recopie (ou constructeur de copie) a un unique argument du même type que l’objet à créer (généralement sous forme de référence constante) et il recopie les attributs depuis l’objet passé en argument sur l’objet à créer.
3. Le constructeur paramétrique appelé si la signature correspond à celle du constructeur.

• Les accesseurs (get) et les mutateurs (set) : ces méthodes spéciales permettent d’appeler les propriétés et modifier les propriétés d’une classe depuis l’extérieur, un peu comme une API. C’est grâce à elles que l’extérieur peut « appeler » les fonctionnalités de la classe. Les accesseurs permettent de récupérer la  valeur des propriétés d’une instance de classe depuis l’extérieur sans y accéder directement. Ce faisant, ils sécurisent l’attribut en restreignant sa modification. Les mutateurs quant à eux permettent de modifier la valeur des propriétés tout en vérifiant que la valeur que  l’on veut donner à l’attribut respecte les contraintes sémantiques qui ont été imposées à la classe.
• Le destructeur : est une méthode qui met fin à la vie d’une instance de classe. Il peut être appelé à la suppression de l’objet, explicitement ou implicitement.

Pour rendre toutes ces explications sur le concept de classe concrètes, prenons l’exemple précédent de la voiture et implémentons-le dans le langage Java. La classe se définit suivant cette syntaxe :

public class NomDeLaClasse {...}

Implémentons complètement la classe Voiture en Java. Voici ce que cela donne :

public class Voiture{

	//Déclaration des attributs
	private String couleur;
	private double poids;
	private int prix;
	  
	//Déclaration des méthodes
	void demarrer(){...}
	void accelerer(){...}

      // accesseur sur couleur
	public String getCouleur(){ 
		return this.couleur; 
	}
	
	//mutateur sur couleur
	public void setCouleur(String uneCouleur){ 
		this.couleur = uneCouleur;
	}

}

L’ identifiant d’une méthode est défini par sa signature. On appelle signature d’une méthode l’ensemble formé par son nom et la liste des types de ses arguments. Deux méthodes peuvent avoir le même nom si elles se distinguent par leurs signatures : c’est la surcharge des méthodes. Nous y reviendrons plus bas…

Le concept d’objet

Le second concept le plus important en programmation objet c’est justement, l’objet. Comme nous vous l’avons dit tout à l’heure, un objet est une instance de classe. Pour faire le parallèle avec le monde réel, l’objet c’est un peu comme une maison bâtit sur la base d’un plan particulier. Tant que les architectes se réfèrent à ce plan, ils produiront toujours les mêmes maisons.

Techniquement, un objet est caractérisé par 3 choses :

• une identité : l’identité doit permettre d’identifier sans ambiguïté l’objet (adresse/ référence ou nom)
• des états : chaque objet a une valeur par défaut (lorsqu’elle est indiqué à l’instanciation) pour chacune de ses propriétés. On appelle ces valeurs, des états de l’objet.
• des méthodes :  chaque objet est capable d’exécuter les actions ou le comportement défini dans la classe. Ces actions sont traduites en POO concrètement sous forme de méthodes. Les actions possibles sur un objet sont déclenchées par des appels de ces méthodes ou par des messages envoyées par d’autres objets.

La figure suivante illustre parfaitement le concept d’objet

Les objets ne sont pas des éléments statiques et leur durée de vie ne correspond pas forcément à la durée d’exécution du programme. La durée de vie d’un objet passe par trois étapes :

1.  la déclaration de l’objet et  son instanciation
2. l’utilisation de l’objet en appelant ses méthodes
3. la suppression de l’objet, en appelant son destructeur ou en arrêtant la machine virtuelle qui exécute le programme, ou en arrêtant simplement le programme.

On instancie un objet en JAVA de la façon suivante:

Voiture maVoiture = new Voiture (...) ;

Le concept d’encapsulation

Le troisième concept de la programmation orientée objet c’est l’encapsulation.

les propriétés des objets ne peuvent être accédées que par ses méthodes. Ainsi, la classe encapsule à la fois les attributs et les méthodes qui permettent de manipuler les objets indépendamment de leurs états.

L’encapsulation permet de restreindre l’accès direct aux états et empêche la modification de l’objet hors de ses méthodes. Par exemple, si vous avez une classe Voiture et que vous voulez définir la valeur de sa propriété couleur à bleu, il vous faut passer par une méthode par exemple definirCouleur, implémentée par le développeur de la classe. Cette méthode peut restreindre les différentes valeurs de couleur.

Ainsi, l’encapsulation est un mécanisme qui empêche donc de modifier ou d’accéder aux objets par un autre moyen que les méthodes proposées, et de ce fait, permet de garantir l’intégrité des objets.

L’utilisateur d’une classe n’a pas forcément à savoir de quelle façon sont structurées les méthodes dans l’objet, ni le processus par lequel l’objet obtient tel ou tel état. En interdisant l’utilisateur de modifier directement les attributs, et en l’obligeant à utiliser les fonctions définies pour les modifier, on est capable de s’assurer de l’intégrité des objets. On pourra donc effectuer des contrôles sémantiques sur les données entrées par l’utilisateur.

Dans le schéma précédent, la boîte noire masque les détails d’implémentation des attributs et des actions de la classe. Elle cache les attributs couleur, poids, prix. Le grand avantage de ce procédé est qu’en tant qu’utilisateur, on n’a plus à se préoccuper de comment est fait l’intérieur de l’objet de classe Voiture. On n’a plus besoin de se préoccuper sur le nombre d’attributs dans la classe Voiture. On se contente de connaître comment manipuler une voiture à l’aide des services offerts par la classe.

L’encapsulation permet de définir des niveaux de visibilité des éléments de la classe. Ces niveaux de visibilité définissent ce qu’on appelle la portée (ou encore le périmètre) de la l’attribut/méthode. La portée est ainsi définie par méthode et par attribut et indique les droits à leur accès. Il existe trois niveaux de visibilité :

• Publique (+): les attributs publics sont accessibles à tous
• Protégée (#): les attributs protégés sont accessibles seulement dans la classe elle-même et aux classes dérivées.
• Privée (-): les attributs privés sont accessibles seulement par la classe elle-même.

Regardons le code suivant :

public class Voiture{

	//Déclaration des attributs
	private String couleur;
	private double poids;
	private int prix;
	  
	//Déclaration des méthodes
	void demarrer(){...}
	void accelerer(){...}
	public String getCouleur(){ // accesseur sur couleur
		return this.couleur; 
	}
	
		//mutateur sur couleur
	public void setCouleur(String uneCouleur){ 
		this.couleur = uneCouleur;
	}
}


public class Main{
   public static void main(String args[]){
        Voiture uneVoiture = new Voiture ();
        uneVoiture.poids = 1000;  // Erreur de compilation

        
   }
}

Le script précédent renvoie une erreur lors de son exécution parce que, bien que la classe Voiture possède un attribut « poids », un accesseur n’a pas été défini pour permettre la modification de son état. Du coup, vous voyez que même si l’attribut existe, elle n’est pas accessible à l’extérieur de la classe. C’est ce que permet l’encapsulation.

Le concept d’héritage

L’héritage est le quatrième concept clé de la programmation objet. C’est un concept en POO qui désigne le fait qu’une classe peut hériter des caractéristiques (attributs et méthodes) d’une autre classe.

Les objets de classes peuvent hériter des propriétés d’une classe parent. Par exemple on peut définir une classe Employé et une classe Manager qui est une classe spécialisée de Employé, qui hérite de ses propriétés.

Soient deux classes A et B

• Relation d’héritage : Classe B « étend la  » Classe A
• A est la super-classe ou classe mère/parent de B
• B est la sous-classe ou classe fille de A

Dans l’exemple ci-dessus la classe Voiture et Avion sont des classes filles de la classe Véhicule. On peut les concevoir comme étant des classes spécialisées de la classe Véhicule. Ainsi tout objet de la classe Voiture ou Avion possédera les attributs et méthodes de la Classe Vehicule en plus de ses propres caractéristiques.

En java l’héritage est défini par le mot clé extends.

public class Voiture extends Vehicule {...}
public class Avion extends Vehicule {...}

Une méthode dans une classe mère peut être redéfinie dans une classe fille : on parle de redéfinition. La nouvelle définition remplace celle héritée pour les objets de la classe dérivée. Le remplacement est effectif même quand l’objet de la classe fille est référencé par une variable typée par la super-classe (polymorphisme). Nous allons y revenir.

Implémentons toutes les notions vues ci-dessus par rapport à l’héritage en JAVA.

public class Point{

    protected int x, y;
    private void affiche(){
	System.out.println("x = "+ this.x + " y = " + this.y); 
    }

    Point (int x, int y){this.x = x; this.y = y;}
}

public class PointColore extends Point{
    private String couleur;
    PointColore(int x, int y, String couleur){
	      super(x, y); // appel du constructeur de la classe mère
	      this.couleur = couleur;
	 }

	 public void affiche()         //redéfinition de affiche()
	 {
	   super.affiche();            //appel à affiche() de la classe mère
	   System.out.println(" couleur = " + this.couleur);
	 } 
	
	}

	public class Main{

	   public static void main(String args[]){
	        Point p = new Point (5, 2);
	        PointColore pc = new PointColore(7, 4, "verte");
	        p.affiche(); //x = 5  et y = 2;
	        pc.affiche(); // x = 7 et y = 4 couleur = verte
	   }
}

L’héritage présente 2 avantages principaux en POO :

• la spécialisation : une nouvelle classe réutilise les attributs et les méthodes d’une classe en y ajoutant des opérations particulières à la nouvelle classe.
• la réutilisation : pour chaque classe spécialisé, on n’a pas besoin de recréer à chaque fois la même classe.

Le concept de polymorphisme

Le dernier concept clé de la programmation orientée objet c’est le polymorphisme. Un langage orienté objet est dit polymorphique, s’il offre la possibilité de percevoir un objet en tant qu’instance de différentes classes selon la situation. Java par exemple, est un langage  polymorphique. Nous allons expliquer ce concept avec des exemples concrets. Supposez le code Java suivant :

public class A {

	public void f();
}

public class B extends A {

	public void k();
}

public class Main{

	public static void main (String [] args){
		A a1 = new B (...);//upcasting
	} 

}

En examinant le code attentivement, vous remarquerez qu’à  une  référence de type A,  on affecte une référence vers un objet de la classe B : on parle de surclassement ou upcasting.

A la compilation a1 est considéré comme un objet de classe A. Ses services sont alors réduits à celles proposées par la classe A.

public class Main{

	public static void main (String [] args){
		A a1 = new B(...);
		a1.f(); //ok
		a1.k(); // erreur de compilation
	} 
	
}

Prenons un autre exemple.

public class Main{
  public static void main (String [] args){
    A a1 = new B(...);       				  			
    B b1 = (B) a1; // downcasting
} 

Dans le code ci-dessus  nous remarquons qu’à  une  référence de type B  on affecte une référence vers un objet de type A après une conversion : on parle de downcasting.

Le concept de classe abstraite

Le concept de classe abstraite ne fait pas partie des concepts clés de la POO, puisque c’est un type de classe. Par contre, vu son utilité des les cas d’usage du Big Data, nous avons jugé indispensable d’en parler.

En programmation orientée objet, une classe abstraite est une classe dont l’implémentation n’est pas complète et n’est pas instanciable. C’est une classe qui sert de base à d’autres classes dérivées (héritées). 

Une classe abstraite est définie de la façon suivante en Java :

public abstract class NomClasse {
  ...
}

L’intérêt d’une classe abstraite est que l’on peut y placer toutes les fonctionnalités dont on souhaite disposer pour ses classes dérivées :

• soit sous forme d’une implémentation complète de méthodes et de champs dont héritera toute classe dérivée
• soit alors sous forme d’interface de méthodes abstraites dont on est alors sûr qu’elles existeront dans toute classe dérivée instanciable.

Une méthode abstraite est une méthode dont on ne  fournit que la signature. Elle doit obligatoirement être public. On déclare une méthode abstraite de la façon suivante:

public abstract void uneMethode (...);

Règles d’utilisation des classes abstraites :

• Une classe est automatiquement abstraite si  une de ses méthodes est abstraite
• Une classe abstraite n’est pas instaciable (on ne peut pas utiliser les constructeurs d’une classe abstraite et donc on ne peut pas créer d’objet ou d’instance de cette classe).
• Une classe qui hérite d’une classe abstraite ne devient concrète que si elle implémente toutes les méthodes abstraites  de la classe dont elle hérite.
• Une méthode abstraite n’est pas implémentée, mais doit être implémentée dans les sous-classes non abstraites.
• Une classe abstraite peut contenir des méthodes non abstraites et des déclarations d’attributs ordinaires.

L’implémentation en Java des classes de cette figure donne ceci :

public abstract class Forme{

    protected String couleur;
    public abstract double surface();
    public abstract void affiche();
}

public class Cercle extends Forme{

 private double rayon;
 public Cercle (String couleur, double rayon){
   super();
	   this.couleur = couleur;
	   this.rayon = rayon;
	 }

	 @Override
	    public double surface() {
	        return Math.PI * this.rayon * this.rayon;
	}

   @Override
   public void affiche() {
       System.out.println("[couleur = " + this.couleur + ", rayon = " + this.rayon + " ]") ;
    }
}

public class Rectangle extends Forme{

    private double longueur;
    private double largeur;

    public Rectangle(String couleur, double longueur, double largeur){
        this.couleur = couleur;
        this.longueur = longueur;
        this.largeur = largeur;
    }

    @Override
	public double surface() { 
		 return longueur * largeur;
	}

	@Override
	public void affiche() {
	   System.out.println("[couleur = " + this.couleur + ", longueur = " + this.longueur + ", largeur = "+ this.largeur + " ]") ;

	}
}
	

public static void main(String[] args) {

      Cercle c1 = new Cercle("vert", 2);
      Rectangle r1 = new Rectangle("bleu", 4, 5);

      c1.affiche(); // ok  [couleur = vert, rayon = 2.0 ]
      r1.affiche(); //ok   [couleur = bleu, longueur = 4.0, largeur = 5.0 ]

      Forme f1 = new Forme(); //erreur de compilation

}

Le concept d’interface

L’interface, même s’il n’est pas un concept fondamental de l’orienté objet, reste tout de même très important. C’est pourquoi, tout comme les classes abstraites, nous estimons qu’il est indispensable que vous vous familiarisez avec le concept.

Une interface est un ensemble de signatures de méthodes, qui sont par essence abstraites et publiques/constantes. Une interface est déclarée avec le mot clé interface.

Une classe peut implémenter une ou plusieurs interfaces à l’aide du mot clé implements, c’est à dire implémenter toutes les méthodes abstraites de l’interface. C’est l’héritage multiple en Java.

Les constantes d’une interface sont accessibles à toutes les classes implémentant l’interface.

public interface I1{
	
    static final int MIN = 25;
    void fonction1();
	
}
	
public interface I2{
	
    void fonction2();
}

public class A implements I1, I2{

	//Les méthodes fonction1 fonction2 des interfaces I1 et //I2 doivent être définies dans	la classe A
	 
	//dans toutes les méthodes de la classe A on a accès à // la constante MIN
	
}

Une interface ne permet pas d’instancier des objets, mais on peut définir des variables de type interface, qui peuvent référencer des objets d’une classe implémentant une interface.

Les autres concepts du paradigme orienté objet : les mixins

Dans les langages de programmation orientés objet, un mixin est une classe qui contient des méthodes pouvant être utilisées par d’autres classes sans avoir à être la classe parente de ces autres classes.

La manière dont ces autres classes accèdent aux méthodes du mixin dépend du langage. Les mixins sont parfois décrites comme étant « incluses » plutôt qu »héritées ».

Les mixins encouragent la réutilisation du code et peuvent être utilisés pour éviter l’ambiguïté que peut causer  l’héritage multiple  (le « problème du diamant »), ou pour contourner le problème du manque d’héritage multiple dans un langage.

Un mixin peut également être considéré comme une interface avec les méthodes implémentées. Ce pattern est un exemple d’application du principe d’inversion des dépendances.

Nous sommes arrivés au terme de cette chronique complète sur la programmation orientée objet. L’objectif était de vous familiariser avec ses concepts principaux, car aujourd’hui, vous ne développerez pas des applications efficaces (surtout dan le Big Data) sans y avoir recours. Nous espérons que la chronique vous a plu et vous a donné envie d’aller plus loin.

En guise de conclusion, nous dirons que la programmation orientée objet est aujourd’hui l’approche la plus adaptée pour le développement applicatif. Les langages de POO vous permettent de décomposer votre logiciel en petits problèmes que vous pouvez ensuite résoudre, un objet à la fois. Cela ne veut pas dire que la POO est la seule méthode. Vous pouvez combiner vos applications d’objets et de composants d’autres paradigmes de programmation (comme le paradigme de programmation fonctionnel). D’ailleurs, dans la pratique, c’est ce que vous serez emmené à faire le plus souvent. Ne voyez donc pas la POO comme un paradigme différent et complètement séparé des autres. Voyez-le plutôt comme un paradigme complémentaire qui s’ajoute à la boîte à outils dont vous disposez déjà pour développer toutes sortes d’applications de traitement de données. Si vous souhaitez aller plus loin dans l’apprentissage de la programmation, et commencer dès maintenant à mettre en pratique ce que vous avez appris dans cette chronique, alors téléchargez cette vidéo de cours de 60 min sur Scala.