Quel est l’objectif du codage dans la conception du code du système d’information de gestion ?

Le but du codage est : l’unicité, la standardisation et la systématisation. Les codes utilisent des chiffres ou des caractères pour représenter diverses entités objectives. Le but de la conception de codes pendant le processus de développement du système est : l'unicité, la normalisation et la systématisation.

Le code utilise des chiffres ou des caractères pour représenter diverses entités objectives. Le but de la conception du code pendant le processus de développement du système est :

1. Unique;

2. Normalisation

3.

Six principes de conception de code

Principe de responsabilité unique

Définition : Une classe A ou une interface n’est mieux responsable que d’une seule responsabilité.

Origine du problème : La classe T est responsable de deux responsabilités différentes P1 et P2. Étant donné que la responsabilité P1 doit être modifiée et que la classe T doit être modifiée, cela peut entraîner un dysfonctionnement de la fonction de la responsabilité P2 qui fonctionnait normalement à l'origine.

Solution : Suivez le principe de responsabilité unique. Créez respectivement de nouvelles classes pour correspondre aux responsabilités correspondantes ; de cette façon, vous pouvez éviter que la modification de la classe n'affecte d'autres responsabilités

Lorsque vous rencontrez la prolifération des responsabilités, seulement lorsque la logique est assez simple, en violant le ; Principe de responsabilité unique au niveau du code. Ce n'est que lorsque le nombre de méthodes dans une classe est suffisamment petit que le principe de responsabilité unique peut être violé au niveau de la méthode.

Avantages : La complexité de la classe sera ; réduit et la lisibilité sera réduite. Elle sera grandement améliorée et la maintenabilité sera également améliorée.

Principe de substitution de Liskov

Partout où une classe de base est utilisée, ses sous-classes peuvent être utilisées arbitrairement, garantissant que la sous-classe peut parfaitement remplacer la classe de base de ce type L'esprit ; est en fait l'incarnation des contraintes et des normes du mécanisme d'héritage. Dans l'implémentation spécifique des classes et sous-classes parentes, les caractéristiques des relations dans la hiérarchie d'héritage sont strictement contrôlées pour garantir que lors du remplacement de la classe de base par une sous-classe, le comportement du programme ne posera pas de problèmes et pourra continuer normalement.

Pour l'héritage, la classe parent définit une série de spécifications et de contrats. Bien qu'il ne soit pas obligatoire que toutes les sous-classes s'y conforment, si la sous-classe modifie arbitrairement ces méthodes non abstraites, l'ensemble du système d'héritage sera affecté. Causer des dégâts.

Si vous devez réécrire la méthode de la classe parent, la méthode la plus courante est la suivante : la classe parent et la sous-classe d'origine héritent toutes deux d'une classe de base plus populaire, suppriment la relation d'héritage d'origine et utilisent la dépendance. , agrégation, combinaison et autres relations ; le principe

comprend les quatre niveaux de signification suivants :

* Une sous-classe peut implémenter la méthode abstraite de la classe parent, mais ne peut pas remplacer la méthode non abstraite de la classe parent Méthodes ;

* Les sous-classes peuvent ajouter leurs propres méthodes uniques

* Lorsqu'une méthode d'une sous-classe remplace une méthode d'une classe parent, les paramètres formels de la méthode est plus grande que les paramètres d'entrée de la méthode de la classe parent. Meilleure et plus détendue

* Lorsqu'une méthode d'une sous-classe implémente une méthode abstraite d'une classe parent, la valeur de retour de la méthode est plus stricte ; que celui de la classe parent ;

Principe d'inversion de dépendance

Définition : Les modules de haut niveau ne doivent pas s'appuyer sur des modules de bas niveau, les deux doivent s'appuyer sur leurs abstractions ; les abstractions ne doivent pas s'appuyer sur des détails ; les détails doivent s'appuyer sur des abstractions, et l'idée principale est de s'appuyer sur des abstractions

Origine du problème : la classe A dépend directement de la classe B. Si vous souhaitez changer la classe A en ; dépendent de la classe C, vous devez modifier le code de la classe A. Dans ce scénario, la classe A est généralement un module de haut niveau responsable de la logique métier complexe ; la classe B et la classe C sont des modules de bas niveau responsables des opérations de base si ; la classe A est modifiée, cela entraînera des risques inutiles pour le programme.

Solution : modifiez la classe A pour qu'elle dépende de l'interface I. La classe B et la classe C implémentent chacune l'interface I. La classe A contacte indirectement la classe B et la classe C via l'interface I. La modification de la classe A réduira la probabilité de coût ;

En pratique, nous devons généralement faire les trois points suivants :

* Les modules de bas niveau doivent avoir des classes ou des interfaces abstraites, ou les deux

* Le type déclaré ; des variables doivent être des classes ou des interfaces abstraites autant que possible

* Suivez le principe de substitution de Liskov lors de l'utilisation de l'héritage

Principe de ségrégation d'interface

Définition : le client ne doit pas s'appuyer sur des interfaces dont il n'a pas besoin ; la dépendance d'une classe à l'égard d'une autre classe doit être basée sur la plus petite interface, sinon cela entraînera une pollution de l'interface. La classe A dépend de la classe B via l'interface I, la classe C dépend ; sur la classe D via l'interface I. Si l'interface I n'est pas l'interface minimale pour la classe A et la classe B, alors la classe B et la classe D doivent implémenter les méthodes dont elles n'ont pas besoin. La signification du principe

est : établir ; Pour une seule interface, ne construisez pas une interface énorme et volumineuse. Essayez d'affiner l'interface autant que possible et d'avoir le moins de méthodes possible dans l'interface. C'est-à-dire que nous devrions établir une interface dédiée pour chaque classe au lieu de cela. essayer de construire une énorme interface pour tous ceux qui comptent sur elle pour appeler

Notez que l'interface doit être aussi petite que possible, mais il doit y avoir une limite. flexibilité de programmation, mais si elle est trop petite, le nombre d'interfaces sera aussi petit que possible, ce qui réduit la complexité de conception. Par conséquent, il doit être modéré. Personnalisez les services pour les classes qui s'appuient sur des interfaces. Exposez uniquement à la classe appelante les méthodes dont elle a besoin et masquez les méthodes dont elle n'a pas besoin

Règle :

 ;

* Une interface ne sert qu'un sous-module ou une logique métier et sert à la personnalisation

* Compressez les méthodes publiques dans l'interface via la logique métier pour rendre l'interface plus compacte

;

* Modifiez au maximum les interfaces qui ont été polluées. Si le risque de changement est trop grand, utilisez le mode adaptateur pour transformer

* Selon le métier spécifique, comprenez la logique en profondeur et ; utilisez votre cœur pour contrôler les idées de conception ;

Comment implémenter l'isolation de l'interface, il existe deux méthodes principales :

1. Séparation des délégations, en ajoutant un nouveau type d'interface pour déléguer la demande du client, isoler la dépendance directe entre le client et l'interface, veuillez noter Cela augmentera également la surcharge du système

2. Séparez l'héritage multiple et répondez aux besoins du client grâce à l'héritage multiple d'interfaces ; >Loi de Déméter

Définition : Un objet doit conserver le moins de connaissances sur les autres objets. L'esprit principal est : ne parlez pas à des étrangers. Le sens populaire est qu'un objet doit en savoir moins sur les classes. qui doivent être couplés et associés pour appeler ; cela entraînera une réduction du degré de couplage entre les classes et une dépendance vis-à-vis des autres classes minimisée par chaque classe.

Principe de composition et de réutilisation

Le principe est d'utiliser au maximum la composition/agrégation au lieu de l'héritage

Ouverture et principe de fermeture

Définition : Une entité logicielle telle qu'une classe, un modèle et une fonction doit être fermée à l'extension et à la modification

Solution : Lorsque le logiciel doit changer, essayez de l'étendre ; le comportement de l'entité logicielle Mettre en œuvre des changements au lieu de modifier le code existant pour mettre en œuvre des changements

Principe de responsabilité unique : les classes d'implémentation doivent avoir une seule responsabilité ;

Principe de remplacement de Richter : ne pas détruire le système d'héritage
Principe d'inversion des dépendances : programmation orientée interface ;
Principe d'isolation de l'interface ; : être précis lors de la conception des interfaces Simple ;
Loi de Déméter : réduire le couplage
Principe d'ouverture et de fermeture : schéma général, ouvert à l'expansion ; , fermé à modification ;

• Pour plus de connaissances connexes, veuillez visiter :

  Site Web PHP chinois
 !

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!