On pense que la programmation orientée objet repose sur trois piliers qui offrent au programmeur des avantages par rapport à l'approche procédurale. Ce sont l'encapsulation, l'héritage et le polymorphisme.L'héritage vous permet de vous débarrasser de manière significative de la duplication de code lors de l'utilisation de l'approche orientée objet. Mais en l'utilisant, vous devez toujours vous souvenir d'un des principes de SOLID, appelé Liskov Substitution, qui, à moins que vous n'entriez dans les détails, stipule que l'héritage ne doit être utilisé que comme une implémentation de la relation «est». Autrement dit, la classe du descendant doit "être" une sous-espèce du parent. Par exemple, vous pouvez avoir la classe Bird et ses sous-classes Sparrow (sparrow) et Raven (raven), qui, par exemple, héritent (et peuvent étendre ou modifier) la méthode fly. Cependant, si vous créez un descendant d'Oiseau appelé Pingouin (pingouin) et que sa méthode de vol, par exemple, lève une exception (parce que les pingouins ne volent pas), cela violera le principe de substitution de Liskov. En parlant d'héritage,Il convient également de mentionner un principe important auquel adhère le Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) dans son livre Design Patterns: Elements of Reusable Object-Oriented Software (1994), qui stipule que vous devez essayer utiliser la composition (lorsqu'un objet «contient» un autre objet) au lieu d'hériter autant que possible. En fait, bon nombre des modèles de conception inventés par le «Gang of Four» sont précisément basés sur ce principe.En fait, bon nombre des modèles de conception inventés par le «Gang of Four» sont précisément basés sur ce principe.En fait, bon nombre des modèles de conception inventés par le «Gang of Four» sont précisément basés sur ce principe.En général, dans la pratique, l'héritage est utilisé pour ne pas dire si souvent, même si dans la plupart des cas les bons programmeurs le remplacent par une composition. Le plus souvent, il existe plusieurs implémentations d'une interface, qui sont spécifiées en tant que dépendances dans les classes clientes. Ce qui à son tour vous permet d'utiliser le deuxième pilier de la POO - le polymorphisme. Ce qui vous permet de passer différentes implémentations de dépendances au code client. En raison du fait que les dépendances transmises ont la même interface, le client (selon l'interface) ne se soucie pas de quel objet lui est arrivé et cela permet au programmeur de changer, pendant l'exécution du programme, de quelle manière (quelle implémentation de l'interface) la tâche finale sera résolue. En parlant de POO, on ne peut que mentionner l'encapsulation. Ceci est un élément essentiel de la POO,ce qui permet de créer des abstractions pour masquer les détails d'implémentation de bas niveau tout en réduisant la complexité du développement. Les détails de l'implémentation sont masqués par les modificateurs d'accès aux méthodes telles que private et protected. Lors de la création de classes, vous devez les créer afin que leurs interfaces (méthodes publiques accessibles) fournissent une abstraction cohérente,sinon ce n'est plus OOP (!) . Par exemple, supposons que nous développons un programme qui contrôle le système de refroidissement d'un réacteur nucléaire. L'abstraction convenue de l'interface peut alors se présenter comme suit.CoolingSystem::getTemperature()
CoolingSystem::SetCirculationRate($rate)
CoolingSystem::OpenValve($valveNumber)
CoolingSystem::CloseValve($valveNumber)
Grâce à une interface expressive courte qui forme une abstraction cohérente, nous pouvons travailler avec le système de refroidissement du réacteur sans avoir la moindre idée des détails de mise en œuvre de bas niveau qui sont caractéristiques de la technologie sélectionnée. L'utilisation d'abstractions peut réduire considérablement la complexité du système développé. Et la lutte contre la complexité est le principal impératif technique du développement. Voici quelques autres exemples d'abstractions cohérentes:Système de contrôle de vitesse:- Régler la vitesse
- Obtenir les paramètres actuels
- Restaurer la valeur de vitesse précédente
- Désactiver le système
Moulin à café:- Activer
- Éteindre
- Régler la vitesse
- Commencez à moudre du café
- Arrêtez de moudre du café
Réservoir d'essence:- Remplissez le réservoir de carburant
- Vidanger le carburant
- Obtenez la capacité du réservoir de carburant
- Obtenez le statut du réservoir de carburant
Lampe:Lors de la conception de l'interface d'un objet, déclarez public uniquement les méthodes que le client doit gérer, en masquant tout le reste. Par conséquent, vous devriez obtenir des boîtes noires, dont vous pouvez oublier le périphérique après l'ajout du code de classe. Cette approche peut réduire considérablement la complexité du système développé.