Encapsulation, héritage, compréhension du polymorphisme

Encapsulation, héritage, compréhension polymorphe

1 Encapsulation

C'est-à-dire encapsuler des choses objectives dans des classes abstraites, et la classe peut permettre à ses propres données et méthodes d'être exploitées uniquement par des classes ou des objets de confiance, et cacher des informations à des objets non fiables. L'encapsulation est l'une des caractéristiques de l'orientation objet et la principale caractéristique des concepts d'objets et de classes. En termes simples, une classe est une entité logique qui encapsule des données et du code qui opère sur ces données. Au sein d'un objet, certains codes ou certaines données peuvent être privés et inaccessibles au monde extérieur. De cette manière, les objets offrent différents niveaux de protection pour les données internes afin d'empêcher des parties non liées du programme de modifier accidentellement ou d'utiliser incorrectement les parties privées de l'objet.

2. L'héritage

fait référence à une méthode qui permet à un objet d'un certain type d'obtenir les propriétés d'un objet d'un autre type. Il soutient le concept de classification hiérarchique. L'héritage fait référence à la possibilité d'utiliser toutes les fonctionnalités d'une classe existante et de l'étendre sans avoir à réécrire la classe d'origine. La nouvelle classe créée par héritage est appelée « sous-classe » ou « classe dérivée », et la classe héritée est appelée « classe de base », « classe parent » ou « super classe ». Le processus d'héritage est le processus du général au spécial. Pour obtenir l'héritage, vous pouvez y parvenir via « Héritage » et « Composition ». Il existe deux types de manières d'implémenter le concept d'héritage : l'héritage d'implémentation et l'héritage d'interface. L'héritage d'implémentation fait référence à la possibilité d'utiliser directement les propriétés et les méthodes de la classe de base sans codage supplémentaire ; l'héritage d'interface fait référence à la possibilité d'utiliser uniquement les noms des propriétés et des méthodes, mais la sous-classe doit fournir l'implémentation

; 3. Le polymorphisme

signifie que la même méthode d'une instance de classe a des manifestations différentes dans différentes situations. Le polymorphisme permet à des objets ayant des structures internes différentes de partager la même interface externe. Cela signifie que même si les opérations spécifiques sur différents objets sont différentes, elles (ces opérations) peuvent être appelées de la même manière via une classe commune.

Cinq principes de base

Principe de responsabilité unique SRP (Principe de responsabilité unique)

signifie que la fonction d'une classe doit être unique et ne peut pas être toutes -compris. Tout comme une personne, vous ne devriez pas vous voir confier trop de travail, sinon même si vous serez occupé toute la journée, votre efficacité ne sera pas élevée.

Principe d'ouverture-fermeture OCP (Principe d'ouverture-fermeture)

Un module doit être ouvert en termes d'extensibilité et fermé en termes de variabilité. Par exemple : un module réseau n'avait à l'origine que des fonctions côté serveur, mais il doit maintenant ajouter des fonctions côté client

Ensuite, le code d'implémentation des fonctions côté client doit être ajouté sans modifier le côté serveur. code de fonction. Il est nécessaire qu'au début de la conception, le serveur et le client soient séparés et que les parties publiques soient abstraites.

Le principe de substitution de Liskov LSP (le principe de substitution de Liskov LSP)

Les sous-classes doivent pouvoir remplacer la classe parent et apparaître partout où la classe parent peut apparaître. Par exemple : L'entreprise organise une fête annuelle et tous les salariés peuvent participer à la loterie. Ensuite, qu'ils soient anciens ou nouveaux salariés,

ou qu'ils soient salariés du siège ou salariés expatriés, ils devraient pouvoir le faire. participer à la loterie, sinon l'entreprise ne sera pas harmonieuse.

Le principe d'inversion de dépendance DIP (le principe d'inversion de dépendance DIP) Le concret dépend de l'abstrait, et la couche supérieure dépend de la couche inférieure. Supposons que B est un module inférieur à A, mais B doit utiliser les fonctions de A.

À ce stade, B ne devrait pas utiliser directement la classe concrète dans A : au lieu de cela, B devrait définir une interface abstraite et utilisez-le par A. Pour implémenter cette interface abstraite, B utilise uniquement cette interface abstraite : cela atteint l'objectif d'inversion de dépendance, et B soulage également sa dépendance à l'égard de A. À son tour, A dépend de l'interface abstraite définie par B. Il est difficile d'éviter de s'appuyer sur des modules de couche inférieure via des modules de couche supérieure. Si B dépend également directement de l'implémentation de A, cela peut alors provoquer des dépendances circulaires. Un problème courant est que lors de la compilation du module A, vous devez inclure directement le fichier cpp du module B, et lors de la compilation de B, vous devez également inclure directement le fichier cpp de A.

Le principe de ségrégation des interfaces FAI

Les modules doivent être isolés via des interfaces abstraites au lieu d'être fortement couplés via des classes spécifiques

Tutoriels recommandés : "
Tutoriel PHP" "Java"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!