Explication détaillée de dix principes de conception permettant aux programmeurs Java de se familiariser avec l'orientation objet

Cet article présente principalement en détail les 10 principes de conception Orientés objet que les programmeurs Java devraient connaître. Il a une certaine valeur de référence. Les amis intéressés peuvent s'y référer

Conception orientée objet. Les principes sont au cœur de la programmation OOPS, mais la plupart des programmeurs Java que j'ai vus sont enthousiasmés par les modèles de conception tels que Singleton (cas unique), Decorator (décorateur), Observer (observateur), etc., mais n'y accordent pas suffisamment d'attention. sur l’apprentissage de l’analyse et de la conception orientées objet. Il est important d'apprendre les bases de la programmation orientée objet comme « l'abstraction », « l'encapsulation », le « polymorphisme » et « l'héritage », mais il est tout aussi important de comprendre ces principes de conception afin de créer des conceptions concises et modulaires. Je vois souvent des programmeurs Java de différents niveaux d'expérience qui ne connaissent pas ces principes de conception OOPS et SOLID, ou qui ne connaissent tout simplement pas les avantages d'un principe de conception particulier, ni même comment l'utiliser dans le codage.

(Principes de conception) L'essentiel est de toujours poursuivre le codage ou la conception avec une cohésion élevée et un faible couplage. Le code open source d'Apache et de Sun est de bons exemples pour apprendre les principes de conception Java et OOPS. Ils nous montrent comment les principes de conception sont utilisés dans la programmation Java. Java JDK utilise certains principes de conception : modèle d'usine dans la classe BorderFactory, modèle singleton dans la classe Runtime et modèle décorateur dans la classe java.io. BTW, si vous êtes vraiment intéressé par les principes de codage Java, lisez Effective Java de Joshua Bloch, qui a écrit l'API Java. Mon préféré en matière de modèles de conception orientés objet est Head First Design Pattern de Kathy Sierra, ainsi que d'autres livres sur l'analyse et la conception orientées objet en termes simples. Ces livres sont d'une grande aide pour écrire un meilleur code qui tire pleinement parti de divers modèles de conception orientés objet et SOLID.

Bien que la meilleure façon d'apprendre les modèles de conception (principes) consiste à utiliser des exemples concrets et à comprendre les inconvénients causés par la violation des principes de conception, le but de cet article est d'éduquer les programmeurs Java qui n'ont pas été exposés ou sont en phase d’apprentissage. Une introduction aux principes de conception orientée objet. Personnellement, je pense que les principes de conception OOPS et SOLID ont besoin d'un article pour les présenter clairement. Je ferai de mon mieux pour le faire ici, mais préparez-vous maintenant à parcourir les modèles de conception (principes) suivants :)
DRY – Ne le faites pas. répétez-vous

Notre premier principe de conception orientée objet est : DRY Comme son nom l'indique, DRY (ne vous répétez pas) signifie ne pas écrire de code répété, mais l'abstraire dans des blocs de code réutilisables. . Si vous disposez de deux blocs de code identiques ou plus, envisagez de les résumer dans une méthode distincte ou si vous utilisez plusieurs fois des valeurs codées en dur, faites-en des constantes publiques. L’avantage de ce principe de conception orienté objet est la facilité de maintenance. Il est important de ne pas abuser de ce principe, la duplication n’est pas une question de code mais de fonctionnalité. Cela signifie que si vous utilisez un code commun pour vérifier le OrderID et le SSN, cela ne signifie pas qu'ils sont identiques ou qu'ils resteront les mêmes à l'avenir. En utilisant un code commun pour implémenter deux fonctions différentes, ou si vous associez étroitement ces deux fonctions différentes ; lorsque le format de votre OrderID change, votre code de vérification SSN sera rompu. Faites donc attention à ce couplage, et ne combinez pas des codes similaires qui n'ont rien à voir les uns avec les autres. Encapsulez ce qui change Encapsulez le code qui sera modifié dans le futur. L’avantage de ce modèle de conception orienté objet est qu’il est facile de tester et de maintenir un code correctement encapsulé. Si vous programmez en Java, veuillez respecter les principes suivants :

Les droits d'accès des variables

et des méthodes sont définis sur privé par défaut, et leurs droits d'accès sont progressivement libérés, par exemple de "privé" à " protégé", " non public". Certains modèles de conception en Java utilisent l'encapsulation. Le modèle de conception d'usine en est un exemple. Il encapsule le code qui crée des objets et offre la flexibilité suivante : la génération ultérieure de nouveaux objets n'affecte pas le code existant.

Principe de conception ouvert/fermé

Principe de conception ouvert/ferméLes classes, méthodes/fonctions doivent être ouvertes aux extensions (nouvelles fonctions) et fermées aux modifications . Il s'agit d'un autre principe de conception SOLID élégant pour empêcher quelqu'un de modifier le code qui réussit le test. Idéalement, si vous ajoutez de nouvelles fonctionnalités, votre code sera testé, ce qui est le but du principe de conception on/off. À propos, la lettre « O » dans SOLID fait référence au principe de conception ouvert/fermé.

Principe de responsabilité unique

Principe de responsabilité unique (SRP)

Le principe de responsabilité unique est un autre principe de conception SOLID, et la lettre « S » dans SOLID y fait référence. Selon SRP, il devrait y avoir une et une seule raison pour une modification de classe, ou une classe devrait toujours implémenter une seule fonction. Si une classe Java implémente plusieurs fonctions, une relation de couplage est créée entre ces fonctions ; si vous modifiez l'une des fonctions, vous pouvez rompre la relation de couplage, puis effectuer un autre test pour éviter de nouveaux problèmes.

Injection de dépendances/Principe d'inversion

Principe d'injection de dépendances ou d'inversion

Ne demandez pas quelle est la fonction d'injection de dépendances de le framework sera Quels avantages cela vous apporte-t-il ?La fonction d'injection de dépendances a été bien implémentée dans le framework spring. L'élégance de ce principe de conception est que toute classe injectée par le framework DI peut être facilement testée avec des objets fictifs et est plus simple. à tester. Maintenance, car le code qui crée les objets est centralisé dans le framework et est isolé du code client. Il existe de nombreuses façons d'implémenter l'injection de dépendances, par exemple en utilisant des outils de bytecode, certains frameworks AOP (programmation orientée aspect) tels que les expressions pointcut ou les proxys utilisés au printemps. Pour en savoir plus sur ce principe de conception SOLID, consultez les exemples dans les modèles de conception IOC et DI. La lettre « D » dans SOLID fait référence à ce principe de conception.

Préférez la composition à l'héritage

Favorisez la composition à l'héritage

Si possible, préférez la composition à l'héritage. Certains d’entre vous en discuteront peut-être, mais je trouve que la composition est plus flexible que l’héritage. La composition vous permet de modifier le comportement d'une classe au moment de l'exécution en définissant des attributs. En utilisant le polymorphisme, vous pouvez implémenter la relation de composition entre les classes sous la forme d'une interface et offrir une flexibilité pour modifier la relation de composition. Même Effective Java recommande d'utiliser la composition plutôt que l'héritage.

Principe de substitution de Liskov

Principe de substitution de Liskov LSP

Selon le principe de substitution de Liskov, l'endroit où apparaît la classe parent peut être remplacé par un sous-classe. Par exemple, il ne devrait y avoir aucun problème si une méthode ou une fonction de classe parent est remplacée par un objet de sous-classe. LSP est étroitement lié au principe de responsabilité unique et au principe d’isolation d’interface. Si une classe parent a plus de fonctionnalités que sa classe enfant, elle peut ne pas prendre en charge cette fonctionnalité et violer les principes de conception LSP. Afin de suivre les principes de conception LSP SOLID, les classes ou sous-classes dérivées (par rapport aux classes parentes) doivent améliorer la fonctionnalité plutôt que de la réduire. La lettre « L » dans SOLID fait référence au principe de conception LSP.

Principe d'isolation d'interface

Le principe d'isolation d'interface signifie que si la fonction d'une interface n'est pas nécessaire, alors n'implémentez pas cette interface. Cela se produit principalement lorsqu’une interface contient plusieurs fonctions, mais que la classe d’implémentation n’en a besoin que d’une seule. La conception d'interfaces est une affaire délicate car une fois qu'une interface est publiée, vous ne pouvez pas la modifier sans affecter les classes qui l'implémentent. Un autre avantage de ce principe de conception en Java est que les interfaces ont pour caractéristique que toutes les méthodes de l'interface doivent être implémentées avant qu'une classe puisse l'utiliser, donc utiliser une interface à fonction unique signifie implémenter moins de méthodes.

La programmation est toujours centrée sur les interfaces (plutôt que sur les objets d'implémentation)

La programmation est toujours centrée sur les interfaces (plutôt que sur les objets d'implémentation), ce qui rend la structure du code flexible et tout nouvel objet d’implémentation d’interface est compatible avec la structure de code existante. Par conséquent, en Java, veuillez utiliser des interfaces pour les types de données des variables, les valeurs de retour de méthode et les paramètres de méthode. C'est le conseil de nombreux programmeurs Java, tout comme celui de livres comme Effective Java et Head First Design Patterns.

Principe d'agence

Ne vous attendez pas à ce qu'une seule classe remplisse toutes les fonctions. Vous pouvez déléguer de manière appropriée certaines fonctions à des classes proxy pour la mise en œuvre. Des exemples du principe du proxy sont : les méthodes equals() et hashCode() en Java. Pour comparer si le contenu de deux objets est identique, nous laissons les classes de comparaison elles-mêmes effectuer le travail de comparaison à la place de leurs appelants. Les avantages de ce principe de conception sont les suivants : il n’y a pas de duplication de codage et il est facile de modifier le comportement de la classe.

Résumé

Tous les principes de conception orientée objet ci-dessus peuvent vous aider à écrire du code flexible et élégant : une structure de code avec une cohésion élevée et un faible couplage. La théorie n'est que la première étape, il est plus important pour nous d'acquérir la capacité de découvrir quand utiliser ces principes de conception. Pour savoir si nous avons violé des principes de conception et affecté la flexibilité du code, mais rien au monde n'est parfait, nous ne pouvons pas toujours utiliser des modèles de conception et des principes de conception pour résoudre des problèmes. Ils sont principalement utilisés pour des projets avec de longs cycles de maintenance. Projets de grandes entreprises.

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!