Les sept qualités d'un logiciel exceptionnel
Les sept qualités d'un logiciel exceptionnel
1. Expérience utilisateur
La perception par les utilisateurs de l'utilité, de la convivialité et de l'attrait d'une application selon
la somme de toutes les interactions directes et indirectes.
2. Disponibilité
La capacité d'une application à fonctionner correctement à chaque utilisation.
3. Performances
La vitesse avec laquelle une application exécute une fonction conforme aux besoins
de l'entreprise et aux attentes de l'utilisateur.
4. Évolutivité
La capacité d'une application de traiter des volumes croissants ou décroissants de transactions,
services et données.
5. Adaptabilité
La facilité avec laquelle la fonctionnalité d'une application peut être modifiée ou étendue.
6. Sécurité
Réduire les risques d'attaques et assurer la confidentialité des données, l'intégrité des transactions,
l'authentification des utilisateurs, la vérification des autorisations d'accès des utilisateurs et la
non-répudiation des actions.
7. Économie
Minimiser le coût du développement, de l'exploitation et de la modifi cation d'une application sans
compromettre ses valeurs commerciales ou l'une des six autres qualités de conception.
1. Expérience utilisateur
La perception par les utilisateurs de l'utilité, de la convivialité et de l'attrait d'une application selon
la somme de toutes les interactions directes et indirectes.
2. Disponibilité
La capacité d'une application à fonctionner correctement à chaque utilisation.
3. Performances
La vitesse avec laquelle une application exécute une fonction conforme aux besoins
de l'entreprise et aux attentes de l'utilisateur.
4. Évolutivité
La capacité d'une application de traiter des volumes croissants ou décroissants de transactions,
services et données.
5. Adaptabilité
La facilité avec laquelle la fonctionnalité d'une application peut être modifiée ou étendue.
6. Sécurité
Réduire les risques d'attaques et assurer la confidentialité des données, l'intégrité des transactions,
l'authentification des utilisateurs, la vérification des autorisations d'accès des utilisateurs et la
non-répudiation des actions.
7. Économie
Minimiser le coût du développement, de l'exploitation et de la modifi cation d'une application sans
compromettre ses valeurs commerciales ou l'une des six autres qualités de conception.
What is the difference between VB.NET and C#?
What is the difference between VB.NET and C#?
Well this is the most debatable issue in .NET community and people treat languages like religion.
It is a subjective matter which language is best. Some like VB.NET’s natural style and some like
professional and terse C# syntaxes. Both use the same framework and speed is very much
equivalents. Still let us list down some major differences between them:-
Advantages VB.NET:-
• Has support for optional parameters that makes COM interoperability much easy.
• With Option Strict off late binding is supported.Legacy VB functionalities can be
used by using Microsoft.VisualBasic namespace.
• Has the WITH construct which is not in C#.
• The VB.NET parts of Visual Studio .NET compiles your code in the background.
While this is considered an advantage for small projects, people creating very
large projects have found that the IDE slows down considerably as the project
gets larger.
Advantages of C#
• XML documentation is generated from source code but this is now been
incorporated in Whidbey.
• Operator overloading which is not in current VB.NET but is been introduced in
Whidbey.
• Use of this statement makes unmanaged resource disposal simple.
• Access to Unsafe code. This allows pointer arithmetic etc, and can improve
performance in some situations. However, it is not to be used lightly, as a lot of
the normal safety of C# is lost (as the name implies).This is the major difference
that you can access unmanaged code in C# and not in VB.NET.
Design pattern : 14.Le Pattern Facade
14.Le Pattern Facade
Description:
L'objectif du pattern Facade est de regrouper les interfaces d'un ensemble d'objets en une interface unifiée rendant cet ensemble plus simple à utiliser pour un client.
Le pattern Facade encapsule l'interface de chaque objet considérée comme interface de bas niveau dans une interface unique de niveau plus élevé. La construction de l'interface unifiée peut nécessiter d'implanter des méthodes destinées à composer les interfaces de bas niveau.
Exemple:
Dans un système offrant des services à des clients au moyen d'un service web. Le Système est architecturé sous forme d'un ensemble de composant possédant leur propre interface. Il est possible de donner l'accès à l'ensemble de l'interface de ces composants aux clients du services web mais cette démarche présente deux inconvénients majeurs :
- Certaines fonctionnalités ne sont pas utiles aux clients du service web.
- L'architecture interne du système répond à des exigences de modularité et d'évolution qui ne font pas partie des besoins des clients du service web pour lesquels ces exigences engendrent une complexité inutile.
Le pattern Facade résout ce problème en proposant l'écriture d'une interface unifiée plus simple et d'un haut niveau d'abstraction. Une classe est chargée d'implanter cette interface unifiée utilisant les composants du système.
But:
Le but du pattern Facade est de regrouper les interfaces d'un ensemble d'objets en une interface unifiée.
Solution:
Ecrire une interface unifiée plus simple et d'un haut niveau d'abstraction et une classe est chargée d'implanter cette interface unifiée utilisant les composants du système.
Avantages:
Rend cet ensemble plus simple à utiliser pour un client
Diagramme de classes:
Structure générique du pattern Facade
Participants:
- Facade et son interface constitue la partie abstaite exposée aux clients du système. Cette classe possède des références vers les classes et composants constituant le système et dont les méthodes sont utilisées par la façade pour implanter l'interface unifiée ;
- Les classes et composants du système implantent les fonctionnalités du système et répondent aux requêtes de la façade. Elles n'ont pas besoin de la façade pour travailler.
Collaborations:
Les clients communiquent avec le système au travers de la façade qui se charge, à son tour, d'invoquer les classes et composants du système. La façade ne peut pas se limiter à transmettre des invocations. Elles doit aussi réaliser l'adaptation entre son interface et l'interface des objets du système au moyen de code spécifique.
Appel de code spécifique nécessaire pour l'adaptation des méthode de la façade
Domaines d'utilisation:
- Pour fournir une interface simple d'un système complexe. L'architecture d'un système peut être basée sur de nombreuses petites classes, lui offrant une bonne modularité et des capacités d'évolution. Cependant ces bonnes propriétés du système n'intéressent pas ses clients qui ont besoin d'un accès simple qui répond à leur exigence ;
- Pour diviser un système en sous-système, la communication entre sous-système étant mise en oeuvre de façon abstraite de leur implantation grâce aux façades ;
- Pour systématiser l'encapsulation de l'implantation d'un système vis-à-vis de l'extérieur.
Description:
L'objectif du pattern Facade est de regrouper les interfaces d'un ensemble d'objets en une interface unifiée rendant cet ensemble plus simple à utiliser pour un client.
Le pattern Facade encapsule l'interface de chaque objet considérée comme interface de bas niveau dans une interface unique de niveau plus élevé. La construction de l'interface unifiée peut nécessiter d'implanter des méthodes destinées à composer les interfaces de bas niveau.
Exemple:
Dans un système offrant des services à des clients au moyen d'un service web. Le Système est architecturé sous forme d'un ensemble de composant possédant leur propre interface. Il est possible de donner l'accès à l'ensemble de l'interface de ces composants aux clients du services web mais cette démarche présente deux inconvénients majeurs :
- Certaines fonctionnalités ne sont pas utiles aux clients du service web.
- L'architecture interne du système répond à des exigences de modularité et d'évolution qui ne font pas partie des besoins des clients du service web pour lesquels ces exigences engendrent une complexité inutile.
Le pattern Facade résout ce problème en proposant l'écriture d'une interface unifiée plus simple et d'un haut niveau d'abstraction. Une classe est chargée d'implanter cette interface unifiée utilisant les composants du système.
But:
Le but du pattern Facade est de regrouper les interfaces d'un ensemble d'objets en une interface unifiée.
Solution:
Ecrire une interface unifiée plus simple et d'un haut niveau d'abstraction et une classe est chargée d'implanter cette interface unifiée utilisant les composants du système.
Avantages:
Rend cet ensemble plus simple à utiliser pour un client
Diagramme de classes:
Structure générique du pattern Facade
Participants:
- Facade et son interface constitue la partie abstaite exposée aux clients du système. Cette classe possède des références vers les classes et composants constituant le système et dont les méthodes sont utilisées par la façade pour implanter l'interface unifiée ;
- Les classes et composants du système implantent les fonctionnalités du système et répondent aux requêtes de la façade. Elles n'ont pas besoin de la façade pour travailler.
Collaborations:
Les clients communiquent avec le système au travers de la façade qui se charge, à son tour, d'invoquer les classes et composants du système. La façade ne peut pas se limiter à transmettre des invocations. Elles doit aussi réaliser l'adaptation entre son interface et l'interface des objets du système au moyen de code spécifique.
Appel de code spécifique nécessaire pour l'adaptation des méthode de la façade
Domaines d'utilisation:
- Pour fournir une interface simple d'un système complexe. L'architecture d'un système peut être basée sur de nombreuses petites classes, lui offrant une bonne modularité et des capacités d'évolution. Cependant ces bonnes propriétés du système n'intéressent pas ses clients qui ont besoin d'un accès simple qui répond à leur exigence ;
- Pour diviser un système en sous-système, la communication entre sous-système étant mise en oeuvre de façon abstraite de leur implantation grâce aux façades ;
- Pour systématiser l'encapsulation de l'implantation d'un système vis-à-vis de l'extérieur.
Design pattern : 13.Le Pattern Decorator
13.Le Pattern Decorator
Description:
Le but du pattern Decorator est d'ajouter dynamiquement des fonctions supplémentaires à un objet. Cet ajout de fonctionnalités ne modifie pas l'interface de l'objet et reste transparent vis-à-vis des clients.
Le pattern Decorator constitue une alternative par rapport à la création d'une sous-classe pour enrichir un objet.
Exemple:
Dans un système qui offre des fonctions par catégories de produits, à un client,si nous voulons offrir des fonctionnalités supplémentaires pour une catégorie de produits nous pouvons rajouter une sous-classe spécifique, si on veut rajouter d'autres fonctionnalités une autre catégorie de produit idem nous pourrions rajouter une sur-classe ce qui devient vite complexe. Il est aisé de comprendre que l'utilisation de l'héritage n'est pas adapté à ce qui est demandé pour deux raisons :
- L'héritage est un outil trop puissant pour réaliser un tel ajout de fonctionnalité.
- L'héritage est un mécanisme statique.
Le pattern Decorator propose une autre approche qui consiste à ajouter un nouvel objet appelé décorateur qui se substitue à l'objet initial et qui le référence. Ce décorateur possède la même interface ce qui rend la substitution transparente vis-à-vis des clients.
But:
Le but du pattern Decorator est d'ajouter dynamiquement des fonctions supplémentaires à un objet. Cet ajout de fonctionnalités ne modifie pas l'interface de l'objet et reste transparent vis-à-vis des clients.
Solution:
Le pattern Decorator propose une autre approche qui consiste à ajouter un nouvel objet appelé décorateur qui se substitue à l'objet initial et qui le référence.
Avantages:
On évite d'utiliser des mécanismes statiques.
On garde des objets basiques très simple.
Diagramme de classes:
Structure générique du pattern Decorator
Diagramme des séquences représentant une seule fonctionnalité rajouté
Diagramme des séquences représentant deux fonctionnalités rajoutées
Participants:
ComposantAbstrait est l'interface commune au composant et aux décorateur;
ComposantConcret est l'objet intial auquel de nouvelles fonctionnalités doivent être ajoutées;
Decorateur est une classe abstaite qui détient une référence vers un composant;
DecorateurConcretA et DecorateurConcretB sont des sous-classes concrètes de Decorateur qui ont pour but l'implantation des fonctionnalités ajoutées au composant.
Collaborations:
Le décorateur se substitue au composant. Lorsqu'il reçoit un message destiné à ce dernier, il le redirige au composant en effectuant des opérations préalables ou postérieures à cette redirection.
Domaines d'utilisation:
- Un système ajoute dynamiquement des fonctionnalités à un objet, sans modifier son interface, c'est à dire sans que les clients de cet objet doivent être modifiés.
- Un système gère des fonctionnalités qui peuvent être retirées dynamiquement.
- L'utilisation de l'héritage pour étendre des objets n'est pas pratique, ce qui peut arriver quand leur hiérarchie est déjà complexe.
Description:
Le but du pattern Decorator est d'ajouter dynamiquement des fonctions supplémentaires à un objet. Cet ajout de fonctionnalités ne modifie pas l'interface de l'objet et reste transparent vis-à-vis des clients.
Le pattern Decorator constitue une alternative par rapport à la création d'une sous-classe pour enrichir un objet.
Exemple:
Dans un système qui offre des fonctions par catégories de produits, à un client,si nous voulons offrir des fonctionnalités supplémentaires pour une catégorie de produits nous pouvons rajouter une sous-classe spécifique, si on veut rajouter d'autres fonctionnalités une autre catégorie de produit idem nous pourrions rajouter une sur-classe ce qui devient vite complexe. Il est aisé de comprendre que l'utilisation de l'héritage n'est pas adapté à ce qui est demandé pour deux raisons :
- L'héritage est un outil trop puissant pour réaliser un tel ajout de fonctionnalité.
- L'héritage est un mécanisme statique.
Le pattern Decorator propose une autre approche qui consiste à ajouter un nouvel objet appelé décorateur qui se substitue à l'objet initial et qui le référence. Ce décorateur possède la même interface ce qui rend la substitution transparente vis-à-vis des clients.
But:
Le but du pattern Decorator est d'ajouter dynamiquement des fonctions supplémentaires à un objet. Cet ajout de fonctionnalités ne modifie pas l'interface de l'objet et reste transparent vis-à-vis des clients.
Solution:
Le pattern Decorator propose une autre approche qui consiste à ajouter un nouvel objet appelé décorateur qui se substitue à l'objet initial et qui le référence.
Avantages:
On évite d'utiliser des mécanismes statiques.
On garde des objets basiques très simple.
Diagramme de classes:
Structure générique du pattern Decorator
Diagramme des séquences représentant une seule fonctionnalité rajouté
Diagramme des séquences représentant deux fonctionnalités rajoutées
Participants:
ComposantAbstrait est l'interface commune au composant et aux décorateur;
ComposantConcret est l'objet intial auquel de nouvelles fonctionnalités doivent être ajoutées;
Decorateur est une classe abstaite qui détient une référence vers un composant;
DecorateurConcretA et DecorateurConcretB sont des sous-classes concrètes de Decorateur qui ont pour but l'implantation des fonctionnalités ajoutées au composant.
Collaborations:
Le décorateur se substitue au composant. Lorsqu'il reçoit un message destiné à ce dernier, il le redirige au composant en effectuant des opérations préalables ou postérieures à cette redirection.
Domaines d'utilisation:
- Un système ajoute dynamiquement des fonctionnalités à un objet, sans modifier son interface, c'est à dire sans que les clients de cet objet doivent être modifiés.
- Un système gère des fonctionnalités qui peuvent être retirées dynamiquement.
- L'utilisation de l'héritage pour étendre des objets n'est pas pratique, ce qui peut arriver quand leur hiérarchie est déjà complexe.
Design pattern : 12.Le Pattern Composite
12.Le Pattern Composite
Description:
Le but de pattern Composite est d'offrir un cadre de conception d'une composition d'objets dont la profondeur est variable, cette conception étant basée sur un arbre.
Par ailleurs, cette composition est encapsulée vis-à-vis des clients des objets qui peuvent interagir sans devoir connaître la profondeur de la conception.
Exemple:
Dans un système en arbre où il y a des composants enfants réunis et rattachés à un composant porteur ou mère,chaque composant enfant peut se composer lui même comme composant mère ainsi de suite.
But:
Le but de pattern Composite est d'offrir un cadre de conception d'une composition d'objets dont la profondeur est variable, cette conception étant basée sur un arbre
Solution:
Le pattern Composite unifie l'interface des deux types de société en utilisant la composition récursive. Cette composition récursive est nécessaire car un composant enfant peut posséder des enfants qui possèdent elles-mêmes d'autres enfants. Il s'agit d'une composition en arbre.
Avantages:
La structure de l'application est moins complexe.
Diagramme de classes:
Le pattern Composite en détails
La classe astraite ClassAbstrait détient l'interface destinée aux client. Elle possède deux sous-classes concrètes à savoir ClassEnfantConcretSsEnfant et ClassEnfantConcretAvEnfant cette dernière détenant une association d'agrégation avec la classe ClassAbstrait représentant les liens avec ses enfants.
Participants:
- Composant est la classe abstraite qui introduit l'interface des objets de la composition, implante les méthodes communes et introduit la signature des méthodes qui gèrent la composition en ajoutant ou en supprimant des composants
- Feuille est la classe concrète qui décrit les feuilles de la composition (une feuille ne possède pas de composant);
- Composé est la classe concrète qui décrit les objets composés de la hiérarchie. Cette classe possède une association d'agrégation avec la classe Composant;
- Client est la classe des objets qui accèdent aux objets de la composition et qui les manipulent.
Collaborations:
Les clients envoient leurs requêtes aux composants au travers de l'interface de la classe Composant.
Lorsqu'un composant reçoit une requête, il réagit en fonction de sa classe. Si le composant est une feuille, il traite la requête comme illustré ci-dessous :
Traitement d'un message par une feuille
Domaines d'utilisation:
- Il est nécessaire de représenter au sein d'un système des hiérarchies de composition;
- Les clients d'une composition doivent ignorer s'ils communiquent avec des objets composés ou non.
Description:
Le but de pattern Composite est d'offrir un cadre de conception d'une composition d'objets dont la profondeur est variable, cette conception étant basée sur un arbre.
Par ailleurs, cette composition est encapsulée vis-à-vis des clients des objets qui peuvent interagir sans devoir connaître la profondeur de la conception.
Exemple:
Dans un système en arbre où il y a des composants enfants réunis et rattachés à un composant porteur ou mère,chaque composant enfant peut se composer lui même comme composant mère ainsi de suite.
But:
Le but de pattern Composite est d'offrir un cadre de conception d'une composition d'objets dont la profondeur est variable, cette conception étant basée sur un arbre
Solution:
Le pattern Composite unifie l'interface des deux types de société en utilisant la composition récursive. Cette composition récursive est nécessaire car un composant enfant peut posséder des enfants qui possèdent elles-mêmes d'autres enfants. Il s'agit d'une composition en arbre.
Avantages:
La structure de l'application est moins complexe.
Diagramme de classes:
Le pattern Composite en détails
La classe astraite ClassAbstrait détient l'interface destinée aux client. Elle possède deux sous-classes concrètes à savoir ClassEnfantConcretSsEnfant et ClassEnfantConcretAvEnfant cette dernière détenant une association d'agrégation avec la classe ClassAbstrait représentant les liens avec ses enfants.
La classe ClassAbstrait possède trois méthodes publiques dont une seule est concrète et les deux autres sont abstraites. La méthode concrète est la méthode Operation1() qui ne dépend pas de la composition en enfant de la classe ClasseAbstrait . Quand aux deux autres méthodes, elles sont implantées dans les sous-classes concrètes (ajouteEnfant() ne possède qu'une implantation vide dans ClassEnfantConcretSsEnfant donc elle n'est pas représentée dans le diagramme de classes).
La structure générique du pattern Composite
- Composant est la classe abstraite qui introduit l'interface des objets de la composition, implante les méthodes communes et introduit la signature des méthodes qui gèrent la composition en ajoutant ou en supprimant des composants
- Feuille est la classe concrète qui décrit les feuilles de la composition (une feuille ne possède pas de composant);
- Composé est la classe concrète qui décrit les objets composés de la hiérarchie. Cette classe possède une association d'agrégation avec la classe Composant;
- Client est la classe des objets qui accèdent aux objets de la composition et qui les manipulent.
Collaborations:
Les clients envoient leurs requêtes aux composants au travers de l'interface de la classe Composant.
Lorsqu'un composant reçoit une requête, il réagit en fonction de sa classe. Si le composant est une feuille, il traite la requête comme illustré ci-dessous :
Traitement d'un message par une feuille
Si le composant est une instance de la classe Composé, il effectue un traitement préalable puis généralement envoie un message à chacun de ses composants puis effectue un traitement postérieur. La figure suivante illustre ce cas avec l'appel récursif à d'autres composants qui vont, à leur tour, traiter cet appel soit comme feuille, soit comme composé.
Traitement d'un message par un composé
- Il est nécessaire de représenter au sein d'un système des hiérarchies de composition;
- Les clients d'une composition doivent ignorer s'ils communiquent avec des objets composés ou non.
Design pattern : 11.Le Pattern Bridge
10.Le Pattern Bridge
Description:
Le but pattern Bridge est de séparer l'aspect d'implantation d'un objet de son aspect de représentation et d'interface.
Ainsi,d'une part l'implantation peut être totalement encapsulée et d'autre part l'implantation et la représentation peuvent évoluer indépendamment et sans que l'une exerce une contrainte sur l'autre.
Exemple:
Un Système devant créer deux implantations de classe différentes, mais avec des caractéristiques communes. Il est donc possible d'introduire une sous classe et deux sous-classes concrètes.
Dans un premier temps, les créations des classes concrètes seraient du premier type et dans un second temps de l'autre. Cette sous-classes introduite, doit également être abstraite et avoir également deux sous-classes concrètes pour chaque implantation.
But:
Le but pattern Bridge est de séparer l'aspect d'implantation d'un objet de son aspect de représentation et d'interface.
Solution:
La solution du pattern Bridge consiste donc à séparer les aspects de représentation de ceux d'implantation et à créer deux hiérarchies de classes comme illustré ci-dessous. Les instances de la classe ClassAbstraitPont détiennent le lien implatation vers une instance répondant à l'interface InterfaceImpl.
Avantages:
L'implantation peut être totalement encapsulée et d'autre part l'implantation et la représentation peuvent évoluer indépendamment
Diagramme de classes:
Le pattern Bridge en détails
Participants:
- ClassAbstraitPont est la classe absraite qui représente les objets du domaine. Elle détient l'interface pour les clients et contient une référence vers un objet répondant à l'interface InterfaceImpl.
- ClassConcretDePontA, ClassConcretDePontB sont les classes concrètes qui implantent les méthodes de ClassAbstraitPont.
- InterfaceImpl définit l'interface des classes d'implantation. Les méthodes de cette interface ne doivent pas correspondre aux méthodes de ClassAbstraitPont. Les deux ensembles de méthodes sont différents. L'implantation introduit en général des méthodes de bas niveau et les méthodes de ClassAbstraitPont sont des méthodes de haut niveau.
- ClassImplA, ClassImplB sont des classes concrètes qui réalisent les méthodes introduites dans l'interface InterfaceImpl.
Description:
Le but pattern Bridge est de séparer l'aspect d'implantation d'un objet de son aspect de représentation et d'interface.
Ainsi,d'une part l'implantation peut être totalement encapsulée et d'autre part l'implantation et la représentation peuvent évoluer indépendamment et sans que l'une exerce une contrainte sur l'autre.
Exemple:
Un Système devant créer deux implantations de classe différentes, mais avec des caractéristiques communes. Il est donc possible d'introduire une sous classe et deux sous-classes concrètes.
Dans un premier temps, les créations des classes concrètes seraient du premier type et dans un second temps de l'autre. Cette sous-classes introduite, doit également être abstraite et avoir également deux sous-classes concrètes pour chaque implantation.
But:
Le but pattern Bridge est de séparer l'aspect d'implantation d'un objet de son aspect de représentation et d'interface.
Solution:
La solution du pattern Bridge consiste donc à séparer les aspects de représentation de ceux d'implantation et à créer deux hiérarchies de classes comme illustré ci-dessous. Les instances de la classe ClassAbstraitPont détiennent le lien implatation vers une instance répondant à l'interface InterfaceImpl.
Avantages:
L'implantation peut être totalement encapsulée et d'autre part l'implantation et la représentation peuvent évoluer indépendamment
Diagramme de classes:
Le pattern Bridge en détails
- ClassAbstraitPont est la classe absraite qui représente les objets du domaine. Elle détient l'interface pour les clients et contient une référence vers un objet répondant à l'interface InterfaceImpl.
- ClassConcretDePontA, ClassConcretDePontB sont les classes concrètes qui implantent les méthodes de ClassAbstraitPont.
- InterfaceImpl définit l'interface des classes d'implantation. Les méthodes de cette interface ne doivent pas correspondre aux méthodes de ClassAbstraitPont. Les deux ensembles de méthodes sont différents. L'implantation introduit en général des méthodes de bas niveau et les méthodes de ClassAbstraitPont sont des méthodes de haut niveau.
- ClassImplA, ClassImplB sont des classes concrètes qui réalisent les méthodes introduites dans l'interface InterfaceImpl.
Collaborations:
Les opérations de ClassseAbstraitePont et de ses sous-classes invoquent les méthodes introduites dans l'interface InterfaceImpl.
Domaines d'utilisation:
- Pour éviter une liaison forte entre la représentation des objets et leur implantation, notamment quand l'implantation est sélectionnée au cours de l'exécution de l'application;
- Pour que les changements dans l'implantation des objets n'aient pas d'impact dans les interactions entre les objets et leurs clients.
- Pour Permettre à la représentation des objets et à leur implantation de conserver leur capacité d'extension par la création de nouvelles sous-classes ;
- Pour éviter d'obtenir des hiérarchies de classes extrêmement complexes.
Inscription à :
Articles (Atom)