Question

Le principe ouvert/fermé stipule que les entités logicielles (classes, modules, etc.) doivent être ouvertes à l'extension, mais fermées à la modification.Qu’est-ce que cela signifie et pourquoi est-ce un principe important d’une bonne conception orientée objet ?

Était-ce utile?

La solution

Plus précisément, il s'agit d'un "Saint Graal" de conception en POO consistant à rendre une entité suffisamment extensible (par sa conception individuelle ou par sa participation à l'architecture) pour supporter de futurs changements imprévus sans réécrire son code (et parfois même sans recompiler). **).

Certaines façons d'y parvenir incluent le polymorphisme/l'héritage, la composition, l'inversion du contrôle (a.k.a.DIP), programmation orientée aspect, modèles tels que stratégie, visiteur, méthode de modèle et de nombreux autres principes, modèles et techniques d'OOAD.

** Voir les 6 "principes du package", REP, CCP, CRP, ADP, SDP, SAP

Autres conseils

Cela signifie que vous devez mettre du nouveau code dans les nouvelles classes/modules.Le code existant doit être modifié uniquement pour la correction de bogues.Les nouvelles classes peuvent réutiliser le code existant via l'héritage.

Le principe ouvert/fermé vise à atténuer les risques lors de l’introduction de nouvelles fonctionnalités.Puisque vous ne modifiez pas le code existant, vous pouvez être assuré qu'il ne sera pas cassé.Cela réduit les coûts de maintenance et augmente la stabilité du produit.

C'est la réponse au problème fragile des classes de base, qui dit que des modifications apparemment innocentes des classes de base peuvent avoir des conséquences involontaires sur les héritiers qui dépendaient du comportement précédent.Vous devez donc faire attention à encapsuler ce sur quoi vous ne voulez pas vous fier afin que les classes dérivées obéissent aux contrats définis par la classe de base.Et une fois que les héritiers existent, il faut être vraiment faites attention à ce que vous modifiez dans la classe de base.

Plus spécifiquement que DaveK, cela signifie généralement que si vous souhaitez ajouter des fonctionnalités supplémentaires ou modifier la fonctionnalité d'une classe, créez une sous-classe au lieu de modifier l'originale.De cette façon, toute personne utilisant la classe parent n’a pas à s’inquiéter de sa modification ultérieure.Fondamentalement, tout est question de compatibilité ascendante.

Un autre principe très important de la conception orientée objet est le couplage lâche via une interface de méthode.Si la modification que vous souhaitez apporter n’affecte pas l’interface existante, vous pouvez la modifier en toute sécurité.Par exemple, pour rendre un algorithme plus efficace.Les principes orientés objet doivent également être tempérés par le bon sens :)

Les entités logicielles doivent être ouvertes à l'extension mais fermées à la modification

Cela signifie que toute classe ou module doit être écrit de manière à pouvoir être utilisé tel quel, étendu, mais jamais modifié.

Mauvais exemple en Javascript

var juiceTypes = ['Mango','Apple','Lemon'];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}

exports.makeJuice = juiceMaker;

Maintenant, si vous souhaitez ajouter un autre type de jus, vous devez éditer le module lui-même. De cette façon, nous cassons OCP.

Bon exemple en Javascript

var juiceTypes = [];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}
function addType(typeName){
    if(juiceTypes.indexOf(typeName)==-1)
        juiceTypes.push(typeName);
}
function removeType(typeName){
  let index = juiceTypes.indexOf(typeName)
    if(index!==-1)
        juiceTypes.splice(index,1);
}

exports.makeJuice = juiceMaker;
exports.addType = addType;
exports.removeType = removeType;

Désormais, vous pouvez ajouter de nouveaux types de jus depuis l'extérieur du module sans modifier le même module.

Le principe signifie qu'il doit être facile d'ajouter de nouvelles fonctionnalités sans avoir à modifier les fonctionnalités existantes, stables et testées, ce qui permet d'économiser du temps et de l'argent.

Souvent, le polymorhisme, par exemple à l’aide d’interfaces, est un bon outil pour y parvenir.

Une règle générale supplémentaire pour se conformer à OCP consiste à rendre les classes de base abstraites en ce qui concerne les fonctionnalités fournies par les classes dérivées.Ou, comme le dit Scott Meyers, « Rendre les classes non-feuilles abstraites ».

Cela signifie avoir des méthodes non implémentées dans la classe de base et implémenter ces méthodes uniquement dans des classes qui elles-mêmes n'ont pas de sous-classes.Le client de la classe de base ne peut alors pas s’appuyer sur une implémentation particulière dans la classe de base puisqu’il n’y en a pas.

Je veux juste souligner que "Ouvert/Fermé", même s'il est évidemment utile en programmation OO, est une méthode saine à utiliser dans tous les aspects du développement.Par exemple, d'après ma propre expérience, c'est un excellent analgésique d'utiliser « Ouvert/Fermé » autant que possible lorsque vous travaillez avec du C simple.

/Robert

Cela signifie que le logiciel OO doit être basé sur, mais pas modifié intrinsèquement.C'est une bonne chose car cela garantit des performances fiables et prévisibles à partir des classes de base.

On m'a récemment donné une idée supplémentaire de ce qu'implique ce principe :que le principe ouvert-fermé décrit à la fois une manière d'écrire du code, ainsi que le résultat final de l'écriture de code de manière résiliente.

J'aime penser à l'Ouvert/Fermé divisé en deux parties étroitement liées :

  • Code qui est Ouvrir modifier peut soit modifier son comportement pour gérer correctement ses entrées, soit nécessiter une modification minimale pour permettre de nouveaux scénarios d'utilisation.
  • Code qui est Fermé la modification ne nécessite pas beaucoup, voire aucune, intervention humaine pour gérer de nouveaux scénarios d'utilisation.Le besoin n’existe tout simplement pas.

Ainsi, le code qui présente un comportement Ouvert/Fermé (ou, si vous préférez, remplit le principe Ouvert/Fermé) nécessite peu ou pas de modifications en réponse à des scénarios d'utilisation au-delà de ce pour quoi il a été initialement conçu.

En ce qui concerne la mise en œuvre ?Je trouve que l'interprétation couramment déclarée, "Open / Fermé se réfère au code polymorphe!" pour être au mieux une déclaration incomplète.Le polymorphisme dans le code est un outil permettant d'obtenir ce type de comportement ;Héritage, implémentation... en réalité, chaque principe de conception orientée objet est nécessaire pour écrire du code résilient de la manière qu'implique ce principe.

Dans le principe de conception SOLID – le « O » dans « SOLID » représente le principe ouvert/fermé.

Le principe Open Closed est un principe de conception qui dit qu'une classe, des modules et des fonctions doivent être ouverts pour extension mais fermés pour modification.

Ce principe stipule que la conception et l'écriture du code doivent être effectuées de manière à ce que de nouvelles fonctionnalités soient ajoutées avec un minimum de modifications dans le code existant (code testé).La conception doit être réalisée de manière à permettre l'ajout de nouvelles fonctionnalités en tant que nouvelles classes, en gardant autant que possible le code existant inchangé.

Avantage du principe de conception ouvert et fermé :

  1. L'application sera plus robuste car nous ne modifions pas la classe déjà testée.
  2. Flexible car nous pouvons facilement nous adapter à de nouvelles exigences.
  3. Facile à tester et moins sujet aux erreurs.

Mon article de blog à ce sujet :

http://javaexplorer03.blogspot.in/2016/12/open-closed-design-principle.html

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top