Programmation orientée objet : Comprendre les interfaces
À ce stade, je dirais que les bases de la compréhension de la programmation orientée objet ont été posées.
Plus précisément, j’ai couvert:
Et, oui, il y a un débat sur ce qui constitue les fondations (c’est-à-dire que certains ne mélangent pas le polymorphisme dans le mélange, bien que je le fasse). Mais les quatre ci-dessus devraient fournir une base solide sur laquelle continuer à développer vos compétences en programmation orientée objet.
Il y en a d’autres, mais je ne pense pas qu’ils soient aussi profonds, détaillés ou difficiles à comprendre que certains des concepts susmentionnés. Là encore, différentes choses deviennent plus faciles pour les autres.
Quoi qu’il en soit, les deux sujets suivants qu’il est important de comprendre sont :
- Interfaces
- Abstraction
Je parlerai de chacun séparément, mais assurez-vous que vous avez d’abord lu la série Fondamentaux, car les deux sujets ci-dessus vous permettront de vous y fier et d’en tirer parti.
Vague, je sais, mais laissez-moi vous expliquer et ensuite partir de là.
Comprendre les interfaces
De loin, la définition la plus courante d’une interface que vous entendrez probablement est qu’il s’agit d’un contrat. Ce n’est pas faux, mais je pense que cela laisse beaucoup à désirer.
Par exemple, lorsque vous pensez à des contrats, vous pensez probablement à quelque chose de très compliqué, beaucoup de jargon, un processus compliqué pour obtenir quelque chose signé, daté, prêt à fonctionner et ainsi de suite.
Mais quand il s’agit d’interfaces de programmation, ce n’est vraiment pas le cas. En fait, je dirais que la définition d’interfaces peut faciliter la programmation et alléger beaucoup de formalités administratives car cela rend les choses très noires ou blanches quant à ce que quelque chose doit implémenter.
Un mot sur les "interfaces"
Notre industrie utilise le mot «interface» pour deux choses :
- Les concepteurs et les utilisateurs utilisent le terme interface pour décrire ce qu’ils voient et comment ils interagissent avec l’application. Cela inclut des éléments tels que des boutons, des listes déroulantes et d’autres éléments que nous pouvons "toucher".
- Les programmeurs utilisent le terme pour désigner les fonctions qu’une sous-classe doit implémenter pour adhérer à une interface. C’est ce qu’on appelle la "programmation sur une interface".
Ce dernier est ce qui va être discuté dans cet article. Et non, nous n’allons pas utiliser d’exemples typiques comme la programmation d’une interface Animal ou autre. Au lieu de cela, nous verrons comment le faire à partir d’échantillons de code réels.
Programmation sur une interface
Nous définissons la "programmation sur une interface" comme un moyen pour nous d’écrire du code qui implémente les signatures des fonctions définies dans ladite interface.
Mais que sont les signatures de méthode? En termes simples, les signatures de méthode incluent :
- le nom du nom de la fonction,
- les arguments qu’il prend,
- le modificateur de visibilité
Dans le contexte d’une classe, vous le verrez comme ceci :
<?php
class Cache
{
public function set($key, $value)
{
// method implementation
}
}
Facile, non ?
Dans le code ci-dessus, nous pouvons voir que la fonction set accepte une clé et une valeur qui seront utilisées et la fonction est accessible par tout objet qui a une référence à la classe.
Mais les interfaces peuvent également inclure cela. Il y a cependant une mise en garde: les interfaces n’ont pas d’implémentation de méthode.
Donc plutôt que quelque chose comme ça :
<?php
class Cache
{
public function set($key, $value) {
set_transient($key, $value);
}
}
Vous verrez ceci :
<?php
interface iCache
{
public function set($key, $value);
public function get($key);
public function has($key);
}
Mais il y a aussi quelques subtilités à noter dans le code ci-dessus.
- Ce code ne le définit pas comme une classe. Au lieu de cela, il l’appelle une interface.
- Le nom de la classe est précédé d’un ‘i’ pour indiquer qu’il s’agit d’une interface. Ce n’est pas obligatoire ; c’est une convention.
- La méthode n’a pas d’implémentation. Il n’a rien d’autre qu’une signature.
Lorsque nous créons une interface, nous disons, comme mentionné ci-dessus, que quelle que soit la classe implémentant l’interface, elle définira les méthodes qu’elle inclut.
Donc, si nous devions lier tout ce que nous avons vu ci-dessus, l’implémentation finale ressemblerait à ceci (même si nous devrions idéalement conserver cela dans des fichiers séparés) :
<?php
interface iCache {
public function set($key, $value);
public function get($key);
public function has($key);
}
public class SimpleCache implemnents iCache
{
public function set($key, $value)
{
set_transient($key, $value, DAY_IN_SECONDS);
}
public function get($key)
{
if (!$this->has($key))
{
return false;
}
return get_transient($key);
}
public function has($key)
{
return false !== get_transient($key);
}
}
Et c’est ainsi que les interfaces et les classes s’imbriquent.
C’est ça?
En termes simples, oui. Mais d’après mon expérience, j’ai découvert qu’il ne suffit pas de définir les méthodes et de les mettre en œuvre.
Souvent, il est facile de définir des classes, puis de définir l’interface, puis de mettre en œuvre l’interface. Mais c’est complètement à l’ envers. Au lieu de cela, nous devons penser de manière plus stratégique à notre travail.
Plutôt que de reculer dans une interface, ce qui va complètement à l’encontre de l’objectif, nous devons commencer large afin que nos classes puissent se spécialiser dans ce qu’elles font tout en implémentant des fonctionnalités communes non seulement à cette classe, mais à d’autres classes qui peuvent avoir besoin de la même fonctionnalité.
En utilisant l’exemple ci-dessus, nous pouvons avoir un SimpleCache, un TransientCache ou un autre type de cache. Quel que soit le type de cache que nous implémentons, ils implémenteront l’interface et la fonctionnalité sera laissée à la classe implémentant l’interface.
Nous définissons donc à quoi un cache pourrait ressembler à un niveau élevé, mais les classes d’implémentation définiront exactement comment elles fonctionnent.
Si vous êtes un développeur WordPress et que vous cherchez à apprendre à créer des choses au-dessus de l’application en utilisant des techniques pratiques orientées objet, alors pourquoi ne pas rejoindre le site ?