Statement: This series of blog reference "Big Talk design mode", author Geoscience.
Bridging mode: In a software system, some types have changes in two or more dimensions because of their own logic, so how do you deal with this "multidimensional change"? This is going to use bridging mode?? Separate the abstract part from its implementation so that they can change independently.
UML Class Diagrams:
Role Description:
Abstract (abstractroad) Role: Abstract The given definition and save a reference to the implemented object.
Fix abstract (speedway) roles: Extend abstract roles, change and modify the definition of the parent class for abstraction.
Implementation-Abstractcar role: This role gives the interface to the implementation of the role, but does not give a specific implementation. It must be noted that this interface is not necessarily the same as the interface definition of the abstract role, in fact, the two interfaces can be very different.
Implementation-specific (Bus) role: This role gives the implementation of the implemented role interface.
The code reflects:
Icar->run (); echo ": On the freeway. "; }} /** Village Street * Class Street */class Street extends abstractroad{ function Run () { $this->icar->run (); echo ": On the village street. "; }} /** Abstract Auto Interface * Interface ICar */interface icar{ function Run (); /** Jeep * Class Jeep */class Jeep implements icar{ function run () { echo "Jeep Run"; }} /** car * Class car */class car implements icar{ function run () { echo "car Run"; }}
Test code:
/------------------------Bridging Mode test code------------------require_once "./bridge/bridge.php"; $speedRoad =new Speedroad () ; $speedRoad->icar=new Car (); $speedRoad->run (); echo "
"; $street =new Street (); $street->icar=new Jeep (); $street->run ();
Applicable scenarios:
1. If a system needs to add more flexibility between the abstract and materialized roles of the artifacts, avoid establishing a static connection between the two levels.
2. Design requires that any change to the implementation role should not affect the client, or that the change to the implementation role is completely transparent to the client.
3. A component has more than one abstract role and an implementation role, and the system requires dynamic coupling between them.
4. While there is no problem with using inheritance in the system, the design requirements need to be managed independently because the abstract and materialized roles need to change independently.
PHP Object-oriented design pattern