PHP orienté objet trois fonctionnalités de base et cinq principes de base

Le contenu de cet article est de partager avec vous les trois fonctionnalités de base et les cinq principes de base du PHP orienté objet. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. 🎜>

Les trois caractéristiques principales sont :

Encapsulation, héritage, polymorphisme

La soi-disant

encapsulation signifie encapsuler des choses objectives dans des classes abstraites, et les classes peuvent Vos propres données et méthodes permettent uniquement aux classes ou objets approuvés de fonctionner et masquent les informations aux objets non fiables.

L'encapsulation est l'une des caractéristiques de l'orientation objet et constitue la principale caractéristique des concepts d'objet et de classe. 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.

Le soi-disant

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 prend en charge 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 d'étendre ces fonctionnalités 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

; Ce qu'on appelle le

polymorphisme signifie que la même méthode d'une instance de classe a différentes manifestations 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 souhaite maintenant ajouter des fonctions côté client
Ensuite, le code d'implémentation des fonctions côté client doit être ajouté sans modifier le code de fonction côté serveur. Cela nécessite que dans la conception, dès le début, le serveur et le client soient séparés et que les parties publiques soient abstraites.

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

La sous-classe doit pouvoir remplacer la classe parent et apparaître partout où la classe parent peut apparaître. Par exemple, si l'entreprise organise une fête annuelle, tous les salariés peuvent participer à la loterie, donc qu'ils soient anciens salariés ou nouveaux salariés,
et qu'ils soient salariés du siège ou salariés expatriés, ils devraient pouvoir 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 soit un module inférieur à A, mais que B doive 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 utiliser 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 concrètes

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!