Introduction to bridge mode

“This is the fifth day of my participation in the August More Text Challenge.

The bridging pattern combines multiple matching uses by separating the abstract from the implementation. In fact, class A contains class B interfaces, and the implementation of class B is passed through constructors. This class B is the bridge of the design.

It is a structural design pattern that splits a large class or series of closely related classes into two separate hierarchies of abstraction and implementation that can be used separately at development time.

It is simply a matter of splitting a complex class/object into an interface (abstraction) and an implementation, using an instance variable in the interface to call a piece of implementation logic (the most important thing in this process is to declare and pass it through constructors).

Bridge mode structure

1. The abstract part: provides the high-level control logic, which depends on the implementation object to do the actual work at the bottom level.

2. Implementation: Declare the common interface for all the details. The abstract part can only interact with the implementation object through the methods declared here.

The abstract part can list the same methods as the implementation part, but the abstract part usually declares complex behaviors that depend on multiple primitive operations declared by the implementation part.

3. Concrete implementation: The object module of the implementation part is inherited from the implementation part.

4. Precise abstractions: Provide variations of control logic that, like their parents, interact with different implementations through implementation interfaces.

Typically, the client only cares about how to work with the abstract part, but the client needs to wire the abstract object with an implementation object.

  • Want to break up or recombine a complex class with multiple functions
  • You want to extend a class on several independent dimensions
  • Different implementations need to be switched at run time

Rather than being a way to organize classes, design patterns can also be used to communicate intent and solve problems.

Advantages and disadvantages of the bridge mode

Advantages:

  • You can create platform-independent classes and programs

  • The client code only interacts with the high-level abstractions and does not touch the platform details (how they are implemented)

  • Meet the open and close principle. You can add abstract and implementation parts without affecting each other

  • Single responsibility principle. The abstraction part focuses on dealing with high-level logic, and the implementation part deals with platform details.

Disadvantages:

  • Use this pattern in other highly cohesive classes, otherwise it will get more complex.

The interfaces in bridge, state mode, and policy mode are very similar. In fact, they are based on a composite pattern: they delegate work to other objects, but each solves a different problem.

The first layer (the abstract part) in the hierarchy will contain references to the second layer (the implementation part) objects. The abstract part can delegate some calls to itself to the objects of the implementation part.

All implementation parts have a common interface, so they can be interchangeable within the abstract parts.

Demo

// </summary> public class Pay {protected IPayMode _padMode; public Pay(IPayMode padMode) { this._padMode = padMode; } public Virtual String Validation(int uId,string uName) {return "+ _padmode.isControl (uId); }}Copy the code

Concrete implementation

// </summary> class zfbPay:Pay {public zfbPay(IPayMode _padMode) : base(_padMode) { } public override string Validation(int uId, string uName) { var isValue =_padMode.IsControl(uId); Return "Alipay is verifying," + isValue + ", user: "+ uName; }}Copy the code
// </summary> class wxPay:Pay {public wxPay(IPayMode padMode) :base(padMode){} public override string Validation(int uId, string uName) { var isValue = _padMode.IsControl(uId); Return "+ isValue+", user: "+uName; }}Copy the code

Interface section

/// <summary> // Payment mode /// face recognition, password recognition /// </summary> Public Interface IPayMode {/// <summary> // Whether the risk control requirements /// </summary> /// <param name="uId"></param> /// <returns></returns> string IsControl(int uId); }Copy the code
/// </summary> public class FaceRecognition: IPayMode {public string IsControl(int uId) {return "face recognition success, your ID is" + uId + "meet the risk control requirements, pay success. ; } /// </summary> public class PasswardInput:IPayMode {public string IsControl(int uId) { Return "Password identified successfully, your ID is" + uId + "Risk control requirements met, payment successful." ; }}Copy the code

The validation test

class Program { static void Main(string[] args) { Pay wxPay = new wxPay(new FaceRecognition()); Var result= wxpay. Validation(001," Validation "); Console.WriteLine(result); Pay zfbPay = new zfbPay(new PasswardInput()); Result = zfbPay. Validation (002, "seven o"); Console.WriteLine(result); Console.ReadKey(); }}Copy the code

Take a closer look at the above code. In the test and verification part, we just need to use which payment mode to directly transfer the value into it, which does not need to relate to the specific internal implementation logic, but also meet the single responsibility principle and the open and closed principle.

Small remarks

Life is short, I don’t want to go after what I can’t see, I just want to catch what I can see.

I am Hui, thank you for reading, if it is helpful to you, please like, forwarding thank you.