POO : Factory et Single Responsability Principle

Voici une proposition de diagramme UML à suivre pour résoudre le challenge ONE_PIECE_1 : (certains éléments du diagramme font référence à PHP mais cette conception vaut pour tous les langages)

Plan

Il y a 2 éléments importants dans cette conception :

• L’utilisation du pattern Factory pour créer des instances de classes similaires
• Le respect du premier principle SOLID le S pour Single Responsability, qui invite à bien séparer le code dans différentes classes, pour que chacun ait sa propre responsabilité dans l’exécution du code

Le pattern Factory

Tu peux faire référence à ce corrigé qui explique le principe.

L’idée ici est de créer une class Person avec les propriétés name et force. Il n’y a rien d’autre dans cette classe. On se rapproche du principe de DTO. On crée ensuite 2 classes enfant : Ally et Ennemy qui vont hériter de Person. Ces classes ne contiennent rien du tout ! Elles sont là vraiment pour mettre en pratique l’héritage ET le pattern Factory.

Enfin, la classe PersonFactory retournera soit une instance de Ally, soit une instance de Ennemy en fonction du second argument.

Fight et AlliesManager

On peut commencer par AlliesManager :

• C’est cette classe qui contiendra les informations des alliés, stockés dans un tableau de « Ally ».
• C’est dans le constructeur qu’on se chargera de remplir allies en utilisant la Factory
• findAlly contient une part importante de la logique du challenge, avec le bon choix de l’allié à réaliser

Et pour Fight, on peut commencer par la fin, voici comment cette classe peut être utilisée :

$fight = new Fight(
    new Ally('LFY', 3),
    new Ally('IVK', 0),
    new AlliesManager($allies)
);

$fight->fight($enemies);

echo $fight->getResult();

Quelques explications :

• Le constructeur nous sert à définir les valeurs définies de l’énoncé, à savoir les informations de Luffy et Ivankov (la valeur de sa force n’a pas d’importance) ET les alliés disponibles, au travers du AlliesManager
• La méthode fight permet de traiter les informations des ennemis, en commencant par instancier un Ennemy grâce à la Factory, puis en passant cet Ennemy en paramètre de la méthode getSequencePartToFight.
• Cette méthode contiendra aussi une part importante de la logique du challenge et fera appel notamment aux propriétés de la classe (fighter, healer et bien sûr alliesManager)
• C’est la méthode fight qui pourra se charger de remplir le tableau sequence.
• Enfin, la méthode getResult sert à formater sequence pour coller au format attendu.

A toi de coder !

N’oublie pas, le but de ce contenu est de proposer une conception permettant de résoudre le challenge avec un code objet et donc de progresser sur cette pratique. Ce n’est pas une réponse absolue et unique 😉

Pour aller + loin

On aurait pu pousser encore davantage la notion de Single Responsability :

• La méthode privée getSequencePartToFight pourrait être dans une classe dédiée à la « stratégie de résolution ». Il y a justement le pattern Strategy qui permet d’organiser le code pour résoudre cette problématique.
• La mise en forme de la séquence pour coller au format attendu pourrait également être dans une classe dédiée, comme « ResultFormater » qui contiendrait une méthode statique liée au format attendu.