--- tags: LPDIM title: POO --- # TP POO -- Kotlin - Principes SOLID ### 👉 Question 1 :::info Peut-on utiliser la classe `Lamp` séparement ? (A-t-on besoins de quelques chose pour l'instancier ?) ::: --- Je pense que l'on peut instancier la classe `Lamp` séparement et l'utiliser comme elle est. ### 👉 Question 2 :::info Peut-on utiliser la classe `Fan` séparément ? (Pareil) ::: --- Je pense que c'est pareil que pour la classe `Lamp`, on peut l'instancier séparement et l'utiliser comme elle est. ### 👉 Question 3 :::info Peut-on utiliser les classes `Button` séparément ? (Idem) ::: --- Je pense que, par contre, la classe `Button` ne peut pas être instancier séparement et qu'elle a besoin d'être utiliser par des objets. En effet, la classe `Button` est une instance et a besoin de l'objet lamp ou de l'objet fan, selon le button, pour pouvoir fonctionner. ### 👉 Question 4 :::info Que ce passe-t-il si un nouveau modèle de lampe sort tout juste sur le marché ? Imaginons que désormais la lampe s’apelle `NeoLamp` que faudrailt-il faire pour lui ajouter un interrupteur ? ::: --- Si un nouveau modèle de lampe sort tout juste sur le marché, il faut pour cela créer une nouvelle classe `Button` que l'on appellera "NeoLampButton" pour utiliser la nouvelle classe `Lamp` nommé "NeoLamp". ### 👉 Question 5 :::info Quel est le problème ? ::: --- Le problème serait, que si à chaque fois, il y a un nouvel objet sur le marché, il faudrait donc créer à chaque fois un nouvel objet avec sa classe button, on se perderait à force de rajouter tout cela. Ce n'est pas une très bonne solution. ### 👉 Question 6 :::info Quels autres solutions peut-on envisager ? ::: --- les solutions que l'on pourrait envisager seraient soit de créer une classe `LesLamp` spécifique pour pouvoir garder la classe `Lamp` sans en créer d'autre à chaque fois ; ou soit faire pareil avec la classe `Button` (commune à tout les objets). ### 👉 Question 7 :::info En quoi dans l’avenir, et sur un code plus complexe, cela peut-il poser des problèmes ? Ici nous pouvons raisoner en terme de nombre de classes modifiées et importance/complexité des classes. ::: --- Dans l'avenir, et sur un code plus complexe, cela pourrait poser des problèmes puisque si une a une classe `LesLamp` qui sert qu'à la classe `Lamp`, que l'on a la classe `LesButton` qui sert qu'à la classe `Button`, etc... Il faudra alors modifier tous les changements des éléments dans chaque classe. ### 👉 Question 8 :::info A quoi peut ressembler l’interface IEquipement ? ::: --- L'interface IEquipement peut ressembler à ça : ```kotlin= interface IEquipment { fun stateOn() { println("ON") } fun stateOff(){ println("OFF") } } ``` ### 👉 Question 9 :::info Implémentez l’interface dans les classes correspodantes. Dans le constructeur de la classe `Button` faites en sorte de dépendre d’abstraction (l’interface) plutot que de l’implémentation (les classes concrètes). ::: --- **Classe Fan :** ```kotlin= class Fan : IEquipment { override fun stateOn() { println("Vent") } override fun stateOff() { println("Rien") } } ``` **Classe Lamp :** ```kotlin= class Lamp : IEquipment { override fun stateOn() { println("Jour") } override fun stateOff() { println("Nuit") } } ``` **Classe Button :** ```kotlin= class Button(private val equipment: IEquipment) { private var state = false fun toggle() { state = !state if (state) { equipment.stateOn() } else { equipment.stateOff() } } } ``` **Classe Hoover :** ```kotlin= class Hoover : IEquipment { override fun stateOn() { println("sale") } override fun stateOff() { println("propre") } } ``` ### 👉 Question 10 :::info Et si finalement je voulais ajouter un autre type de bouton ? Par exemple un interrupteur à réglage variable. Quel impact cela aurait dans le code ? ::: --- Si on voudrait ajouter un autre type de Button comme un interrupteur à réglage variable, il faudrait créer une nouvelle classe `VariableButton` en implémentant l'interface "IEquipement". Grâce à cette classe, on pourra modifier les classes avec ses les objets. Mais cela aurait un impact dans le code. En effet, cette nouvelle classe utilise en paramètre tout les IEquipement, et si un objet est non compatible, cela ne fonctionnera pas. Il faut alors créer un code pour que l'on mette que les IEquipement compatible. ### 👉 Question 11 :::info Admettons que par la suite, en plus d’avoir ce nouveau type de bouton, je dois modifier la classe IEquipement car finalement je veux ajouter un autre type de comportement. Quel sont les impacts dans le code ? Quel est le problème ? ::: --- Si je dois, par la suite, modifier la classe IEquipement ce sera un problème et il y aura un impact dans le code. En effet, mes deux classes, `VariableButton` et `Button`, sont dépendante de la classe IEquipement, et peut être plusieurs autres classes. Si je veux ajouter un autre type de comportement, il faut que je puisse l'adapter à mes deux classes mais ce n'est pas forcément pratique si j'ai, par la suite, plein d'autres types de Button. ### 👉 Question 12 :::info A quoi sert ce Design pattern ? En quoi peut-il être utile dans notre cas ? ::: --- Le design Pattern Adapter permet d'adapter deux objets, composants, interfaces pour qu'ils fonctionnent entres eux. Dans notre cas, il peut être utile car il est utilisé lorsque l'on n'a pas la main sur l'un des objets, ou que l'on ne veut pas le modifier, mais aussi par soucis de compatibilité avec un ancien code par exemple. Il permettrait alors d'avoir une seule instance de Button qui fonctionnerait avec les IEquipement et en même temps on pourrait garder notre classe `Button`. ### 👉 Question 13 :::info En guise de conclusion, pour vous quels sont les avantages de cette façon de faire ? Dans quel cas cela peut-il être utile ? ::: Les avantages de cette façon de faire seraient d'éviter d'avoir trop de classe proche niveau code, qui se ressemble, a réécrire des centaines de fois. Cela pourrait être utile dans le ca de la question 11 par exemple. --- Léa PORTIER - 05/01/2021.