Classes abstraites, partie 2 – Classes abstraites et interfaces

Dans le post précédent de cette série, j’ai parcouru:

• les bases des classes abstraites,
• comment les mettre en œuvre,
• et fourni des exemples de code de travail.

Et bien que je pense que la compréhension des classes abstraites est essentielle pour jeter des bases solides pour la programmation orientée objet, je vois souvent qu’il peut être déroutant de les comparer aux interfaces et de savoir quand les utiliser.

Classes abstraites et interfaces

Alors dans cet article, je vais partager :

• un rappel rapide sur ce que sont les interfaces,
• quelles sont les classes abstraites,
• et ensuite comment savoir quand utiliser l’un plutôt que l’autre.

Cet article ne devrait pas être un article intensif en codage, mais il devrait vous aider à savoir quand écrire du code d’un certain type pour vous aider à mieux organiser vos projets.

1 interfaces

Rappelons que lorsqu’il s’agit d’interfaces, nous utilisons également le terme "programmation vers une interface", l’idée étant que l’interface définit les méthodes qu’une classe doit implémenter pour remplir le "contrat" ​​avec ladite interface.

Le code utilisé pour démontrer une interface de base était :

<?php

interface iCache 
{
  public function set($key, $value);
  public function get($key);
  public function has($key);
}

Mais rappelez-vous, le but de l’interface n’est pas de définir après que le code a été écrit. Au lieu de cela, c’est un outil utilisé pour concevoir ce que les classes doivent implémenter si elles suivent un certain paradigme ou si elles nécessitent un certain ensemble de fonctions.

Autrement dit, si vous allez concevoir un ensemble de classes qui fonctionnent avec la mise en cache, vous n’écrivez pas les classes en premier. Vous écrivez d’abord l’interface, puis les classes implémentent ladite interface.

L’idée est que toute classe implémentant l’interface sera garantie d’avoir ces fonctions.

2 cours abstraits

Les classes abstraites, en revanche, nous permettent de faire deux choses :

1. implémenter des fonctionnalités utilisables par les sous-classes,
2. implémenter les signatures de méthode que les sous-classes doivent implémenter.

Cela peut sembler un peu incongru au début, mais considérez ceci :

Lorsque vous avez une classe d’un certain type qui aura une fonctionnalité cohérente quelle que soit la sous-classe, la fonctionnalité va dans la classe abstraite. Lorsque d’autres méthodes doivent avoir leur implémentation d’une méthode, il vous suffit de fournir la signature de la méthode et de la marquer comme abstract.

Voici un exemple tiré d’un post précédent :

Maintenant, cela nous ramène tous aux exemples précédents et aux choses précédentes sur lesquelles nous devons nous concentrer concernant les interfaces et les classes abstraites, mais pour certains, cela n’apporte toujours pas beaucoup de clarté.

Plus précisément, cela ne répond toujours pas à la question : comment décidons-nous quand utiliser une classe abstraite et quand utiliser une interface ?

À première vue, cela peut sembler un peu déroutant, mais il y a quelques éléments que vous pouvez utiliser pour vous aider à prendre une décision.

Quand utilisons-nous chacun ?

Rappelez-vous qu’en matière de programmation orientée objet, nous pouvons la décomposer en trois manières distinctes :

• Les classes représentent une chose. Vous pouvez les considérer comme un nom.
• Les attributs ou les propriétés sont comme des adjectifs. Ils décrivent l’objet ou quelque chose que l’objet peut contenir.
• Les méthodes ou les fonctions sont comme des verbes. Ils décrivent ce qu’ils peuvent faire.

Maintenant, quand il s’agit d’une interface, pensez à ce que fait l’interface: elle décrit, sans implémentation, ce qu’un objet peut faire. Et quand il s’agit d’une classe abstraite, elle décrit ce qu’est un objet pendant l’exécution.

En d’autres termes, une bonne règle empirique est que si vous devez fournir un ensemble de comportements pour un objet, une interface est une solution. Si vous avez besoin de décrire ce qu’est un objet, utilisez une classe abstraite.

Pour les classes abstraites, j’irais également un peu plus loin et dirais que cela aide à décrire un niveau de base de données qui décrit un objet ou ce qu’il pourrait stocker en plus d’un niveau de base de fonctionnalité.

Vous avez un exemple ?

Comme pour la plupart du contenu de chacun de ces articles, j’essaie de donner des exemples même si ce n’est pas spécifiquement fait dans le code. Peut-être que cela aidera à l’expliquer encore plus:

• Les interfaces n’ont pas d’implémentation. Ils ne garantissent que ce que fera une classe.
• Les classes abstraites doivent avoir un niveau d’implémentation de base. Cela devrait représenter ce qu’une classe peut contenir et faire mais n’est pas complet. Ils nécessitent un peu plus d’implémentation de la sous-classe.

Lorsque vous travaillez avec du code orienté objet, j’espère que cela vous aidera à fournir des indications sur le moment d’utiliser quoi. Sinon, n’hésitez pas à laisser un commentaire (ce que les membres ont la permission de faire :).

De plus, nous verrons cela dans la pratique lorsque nous arriverons à écrire du code orienté objet (notamment pour WordPress, mais pas toujours).