1. Mode pont
Le modèle Bridge est un modèle de conception structurelle qui dissocie l'abstraction de l'implémentation. Il utilise l'interface comme un pont pour séparer le code d'une classe abstraite de sa classe d'implémentation afin qu'ils puissent varier indépendamment. L'idée centrale du modèle de pont est "la composition est meilleure que l'héritage".
Pour faire simple, la fonction d'une classe est contrôlée par deux dimensions, et les deux dimensions ont des implémentations différentes, qui peuvent être combinées à volonté.
Afin d'atteindre l'objectif de faire changer indépendamment la partie abstraite et la partie implémentation, la partie abstraite aura l'objet interface de la partie implémentation. Après avoir l'objet interface de la partie implémentation, la fonction de la partie implémentation spécifique peut être appelé via cette interface. Le pontage est incorporé dans le programme en tant qu'objet d'interface avec la partie abstraite possédant la partie de mise en œuvre, réalisant une relation de pontage. Le pont en mode pont est une relation à sens unique, et seule la partie abstraite peut utiliser l'objet de la partie implémentation.
Rôle de l'abstraction Abstraction : la définition donnée par l'abstraction, qui contient une référence à l'objet réalisé.
Rôle d'abstraction révisé Abstraction raffinée : Étendez le rôle d'abstraction, changez et modifiez la définition de l'abstraction par la classe parente.
Implémenteur de rôle réalisé : Fournit l'interface du rôle réalisé, mais ne donne pas d'implémentation spécifique. Notez que cette interface n'est pas nécessairement la même que la définition d'interface du rôle abstrait, en fait, les deux interfaces peuvent être très différentes. Les rôles réalisés ne doivent fournir que les opérations sous-jacentes, tandis que les rôles abstraits ne doivent fournir que des opérations de niveau supérieur basées sur les opérations sous-jacentes.
ConcreteImplementor : ConcreteImplementor : Implémentation concrète de l'interface du rôle réalisé.
Partie abstraite :
classe abstraite publique Abstraction {
implémenteur d'implémenteur privé ; // La partie abstraite aura l'objet d'interface de la partie d'implémentation, et l'interface agit comme un pont, rendant la fonction de la classe d'implémentation abstraite indépendante de la classe d'implémentation d'interface
abstraction publique (implémenteur ou implémenteur
this.implémenteur = implémenteur ;
}
opération vide publique() {
implémenteur.operationImpl();
}
}
la classe publique RefinedAbstraction étend l'abstraction {
public RefinedAbstraction (implémenteur ou implémenteur) {
super (implémenteur);
}
public void opération raffinée() {
// Étendre la méthode d'opération dans Abstraction
}
}
Partie implémentation :
implémenteur d'interface publique {
void operationImpl();
}
public class ConcreteImplementorA implémente Implementor{
@Passer outre
public void operationImpl() {
//Mise en œuvre
}
}
la classe publique ConcreteImplementorB implémente Implementor{
@Passer outre
public void operationImpl() {
//Mise en œuvre
}
}
À travers la structure, on peut clairement voir que la classe abstraite Abstraction est comme un pont reliant RefinedAbstraction et Implementor.
2. Scénarios d'utilisation du mode pont
① Si un système doit ajouter plus de flexibilité entre le rôle abstrait construit et le rôle concret, et éviter d'établir une relation d'héritage statique entre les deux niveaux, il peut établir une relation d'association au niveau de la couche abstraite via le mode pont.
②Les rôles abstraits et les rôles réalisés peuvent être étendus indépendamment dans le sens de l'héritage sans s'affecter.Lorsque le programme est en cours d'exécution, un objet d'une sous-classe abstraite et un objet d'une sous-classe réalisée peuvent être combinés dynamiquement, c'est-à-dire que le système doit Coupler dynamiquement les rôles de la réalisation et les rôles de la réalisation.
③ Une classe a deux dimensions qui changent indépendamment, et les deux dimensions doivent être développées.
④ Bien qu'il n'y ait aucun problème à utiliser l'héritage dans le système, puisque les rôles abstraits et les rôles concrets doivent changer indépendamment, les exigences de conception doivent gérer les deux indépendamment.
⑤Le mode pont est particulièrement adapté aux systèmes qui ne souhaitent pas utiliser l'héritage ou dont le nombre de classes système augmente fortement en raison de l'héritage à plusieurs niveaux.
3. Avantages et inconvénients du mode pont
1) Avantages :
①Séparation de la partie abstraite et de la partie implémentation
Le mode pont sépare la partie abstraite et la partie mise en œuvre, offrant ainsi une grande flexibilité au système, rendant la partie abstraite et la partie mise en œuvre indépendantes et définissant les interfaces séparément, ce qui aide le système à effectuer une conception hiérarchique, résultant en un système mieux structuré. . Pour la partie de haut niveau du système, il suffit de connaître l'interface entre la partie abstraite et la partie implémentation.
② Meilleure évolutivité
Le mode pont définit respectivement l'interface de la partie abstraite et de la partie implémentation, ce qui permet d'étendre indépendamment la partie abstraite et la partie implémentation sans s'affecter mutuellement, ce qui améliore considérablement l'évolutivité du système.
③La commutation dynamique peut être réalisée
Etant donné que le mode pont réalise la séparation de l'abstraction et de l'implémentation, lors de l'implémentation du mode pont, une sélection dynamique et l'utilisation d'implémentations spécifiques peuvent être réalisées.
④Les détails de mise en œuvre sont transparents pour le client et les détails de mise en œuvre peuvent être cachés à l'utilisateur.
2) Inconvénients :
①L'introduction du mode pont augmente la difficulté de compréhension et de conception du système.Étant donné que la relation d'agrégation est établie au niveau de la couche abstraite, les développeurs doivent concevoir et programmer pour l'abstraction.
②Le mode de pontage nécessite une identification correcte de deux dimensions changeant indépendamment dans le système, de sorte que son champ d'utilisation a certaines limites.
4. Exemple de mode pont
Pour mieux comprendre le modèle de pont, regardons un exemple simple : Supposons que nous ayons une classe de forme, qui a une propriété de couleur. À ce stade, si l'héritage est utilisé pour implémenter des classes de formes de différentes couleurs, de nombreuses sous-classes doivent être créées, ce qui rend la structure du code complexe et difficile à maintenir. En utilisant le mode pont, vous pouvez extraire la forme et la couleur séparément, de sorte qu'elles soient indépendantes.
interface publique Couleur {
Chaîne getColor();
}
classe publique Rouge implémente Couleur {
@Passer outre
chaîne publique getColor() {
retourne "rouge" ;
}
}
classe publique Bleu implémente Couleur {
@Passer outre
chaîne publique getColor() {
retourne "bleu" ;
}
}
classe abstraite publique Shape {
couleur couleur protégée;
Forme publique (couleur) {
this.color = couleur;
}
public abstract void draw();
}
public class Rectangle étend la forme {
public Rectangle(Couleur couleur) {
super(couleur);
}
@Passer outre
public void draw() {
System.out.println("Dessine un rectangle de " + color.getColor() + "");
}
}
public class Circle étend la forme {
cercle public (couleur de couleur) {
super(couleur);
}
@Passer outre
public void draw() {
System.out.println("Dessiner un cercle de " + color.getColor() + "");
}
}
Dans le code ci-dessus, une interface de couleur est d'abord définie, et le rouge et le bleu sont respectivement implémentés. Ensuite, une classe de forme abstraite est définie, qui a un attribut de couleur et une méthode abstraite draw(). Enfin, des classes concrètes de rectangle et de cercle sont implémentées et un objet de couleur est passé dans le constructeur.
De cette façon, la forme et la couleur sont abstraites séparément pour obtenir un découplage. Lorsque vous devez créer des formes de différentes couleurs, il vous suffit de créer des objets de différentes couleurs et de les transmettre.
5. Utilisation dans le code source Android
Le mode pont est utilisé entre Window et WindowManager.
Parmi eux, Window et PhoneWindow constituent la partie abstraite de la fenêtre, Window est l'interface de la partie abstraite, PhoneWindow est l'implémentation concrète et l'extension de la partie abstraite, et WindowManager est la classe de base de la partie implémentation, et WindowManagerImpl est la L'implémentation fait partie de l'implémentation logique spécifique, qui utilise WindowMangerGlobal via L'interface IWindowManager communique avec WMS, et enfin WMS complète la gestion de fenêtres spécifiques. C'est un pont typique impliquant le mode.