Une alternative évolutive à Switch-case : Abstract Factory dans Swift | de Gabriel Moreira | janvier 2023

Cette classe a un paramètre obligatoire dans sa méthode constructeur : le pays à présenter. Il dispose également de trois variables accessibles par la couche de vue : flag, name et description. Ils sont implémentés via une structure switch-case, qui renvoie les valeurs correspondant au pays injecté. De cette façon, nous définissons une expérience spécifique pour chaque pays.

Il s’agit d’une approche très courante lorsque vous travaillez avec des énumérations, et la documentation officielle de Swift recommande son utilisation. Bien qu’il s’agisse d’une structure simple et pratique dans de nombreux cas, certains inconvénients doivent être pris en compte lors de la mise en œuvre de cette solution.

Supposons que dans une deuxième version de l’application, nous souhaitions inclure davantage de pays. De la façon dont c’est implémenté aujourd’hui, la création de nouveaux cas implique d’inclure les mêmes cas dans chacun des commutateurs — sinon, l’application ne se compile pas.

Le problème est que l’inclusion de plus en plus de cas rend les structures de commutation très longues et difficiles à lire. En fait, de nombreuses règles lint fixent une limite au nombre de cas dans une instruction switch pour des raisons de lisibilité. Alors que lorsque cet article a été écrit, il y avait 193 pays reconnus, il n’est pas difficile d’imaginer que ces structures peuvent devenir immenses à mesure que l’application se développe, ce qui rend l’application non évolutive.

Compte tenu des principes SOLID, il y a aussi quelques inconvénients. Le principe de responsabilité unique (SRP) stipule que chaque composant ou fonction ne doit avoir qu’une seule responsabilité ou raison de changement. Dans ce cas, le AfficherModèle les variables ont clairement plus d’une responsabilité, car elles contiennent des données de différents pays.

Et cela viole également le principe ouvert-fermé (OCP), puisque l’ajout de nouveaux pays nécessite de modifier la structure existante. En pensant à l’évolution de l’application, des modèles qui prennent en charge l’évolutivité du système sont souhaitables. Par conséquent, le modèle Abstract Factory peut être très utile ici.

Abstract Factory est un modèle de création qui permet la construction d’objets similaires via une interface, c’est-à-dire sans définir explicitement de classes concrètes.

Ce concept est important car il suit le principe d’inversion de dépendance (DIP), qui détermine que les applications doivent être orientées interface.

Il est défini un protocole appelé CountryAbstractFactory, qui a une fonction pour chaque paramètre des pays. Le protocole est implémenté par les classes concrètes USACountryFactory, CanadaCountryFactory et MexicoCountryFactoryqui sont responsables de la création d’informations sur les États-Unis, le Canada et le Mexique respectivement.

Notez que dans ce cas, toutes les informations exposées par la fabrique sont une chaîne, mais des objets plus complexes peuvent également être utilisés si nécessaire. Pour exposer des classes personnalisées, il serait nécessaire de définir un protocole commun pour elles et de l’affecter comme type de retour de la fonction d’usine. Pour une compréhension plus approfondie, je vous recommande de lire le tutoriel sur le Site Web de RefactoringGuru.

Nous pouvons implémenter cela dans Swift selon le code suivant :