« Bonjour, Amigo ! Nous avons un nouveau sujet fascinant. »

« Décidément c'est la journée des sujets fascinants ! »

« Merci du compliment ! »

« Mais de rien. »

« Tu te souviens de quand nous avons introduit la classe de base ChessItem pour simplifier toutes les classes pour les pièces d'échecs ? »

« Oui. »

« Maintenant, imagine que chaque pièce a une méthode qui gère le rendu de la pièce à l'écran. Tu appelles la méthode et la pièce se dessine elle-même à ses coordonnées actuelles. Serait-il utile de déplacer cette méthode dans la classe de base ? »

« Oui. » Maintenant que j'ai appris le polymorphisme, je pourrais appeler la méthode de rendu pour toutes les pièces, quel que soit leur type. Quelque chose comme ceci : »

Par exemple :
class ChessBoard
{
  public void drawAllChessItems()
  {
  //draw them regardless of their type.
  ArrayList <ChessItem> items = new ArrayList<ChessItem>();
  items.add(new King());
  items.add(new Queen());
  items.add(new Bishop());

  //draw them regardless of their type.
  for (ChessItem item: items)
  {
   item.draw();
  }
 }
}

« C'est super. Exactement. Et que ferait la méthode de rendu de la classe ChessItem elle-même ? »

« Je ne sais pas. Cette pièce n'existe pas aux échecs. Cela veut dire qu'elle n'a pas de représentation visuelle. »

« Précisément. Et ça n'aurait pas de sens de créer un objet ChessItem. Cette pièce d'échecs n'existe pas. C'est seulement une abstraction, une classe que nous avons créée pour des raisons pratiques. C'est comme ça que l'abstraction fonctionne en POO : nous avons déplacé toutes les données et méthodes importantes (partagées par toutes les pièces) dans une classe de base, mais nous avons gardé leurs différences dans les classes correspondant aux pièces spécifiques. »

Classes abstraites - 1

Java a un type de classe spécial pour cela : la classe abstraite. Voici trois choses à retenir à propos des classes abstraites.

1) Une classe abstraite peut déclarer des méthodes sans les implémenter. Une telle méthode est appelée méthode abstraite.

Par exemple :
 public abstract class ChessItem
{
 public int x, y; //coordinates
 private int value; //the piece's "value"

 public int getValue() //an ordinary method, returns value
 {
   return value;
 }

 public abstract void draw(); //abstract method. There is no implementation.

}

2) Une méthode abstraite est marquée avec le mot-clé abstract.

Si une classe a ne serait-ce qu'une seule méthode abstraite, la classe est aussi marquée comme étant abstraite.

3) Tu ne peux pas créer d'objets d'une classe abstraite. Tout code tentant de le faire ne compilera tout simplement pas.

Code Java Description
ChessItem item = new ChessItem();
item.draw();
Ce code ne compilera pas.
ChessItem item = new Queen();
item.draw();
Mais tu peux faire cela.

4) Si ta classe hérite d'une classe abstraite, tu dois écrire toutes les méthodes abstraites héritées, c'est-à-dire les implémenter. Sinon, ta classe devra également être déclarée comme étant abstraite. Si la classe possède ne serait-ce qu'une seule méthode non implémentée déclarée directement dans la classe ou héritée de la classe parente, la classe est considérée comme abstraite.

« Mais pourquoi tout cela est-il nécessaire ? Pourquoi avons-nous besoin des classes abstraites ? N'est-il pas possible d'utiliser des classes ordinaires à la place ? Et au lieu de méthodes abstraites, ne pourrions-nous pas simplement créer des implémentations vides composées uniquement d'accolades ouvrantes et fermantes ? »

« Tu pourrais. Mais ces restrictions sont comme le modificateur private. Nous utilisons le modificateur private pour bloquer délibérément l'accès direct aux données, afin que les autres programmeurs et leurs classes utilisent nos méthodes marquées public. »

Il en va de même pour une classe abstraite. Celui qui a écrit la classe ne veut pas que quiconque crée des instances de la classe. Au contraire, l'auteur s'attend à ce que les méthodes abstraites de sa classe abstraite soient héritées et réécrites.

« Je ne comprends toujours pas pourquoi nous voulons nous compliquer la vie de cette façon. »

« L'avantage de cette fonctionnalité devient évident dans les grands projets. Plus tu as de classes, plus tu dois définir leurs rôles clairement. Tu verras l'avantage de le faire, et très vite. Tout le monde doit passer par là. »