The introduction

Hello, everyone, I am nan Orange, from contact with Java to now also have almost two years of time, two years of time, from a Java even have several data structures do not understand super white, to now understand a little bit of advanced white, learned a lot of things. The more knowledge is shared, the more valuable it is. During this period of time, I summarized (including learning from other leaders, quoted) some key points in daily learning and interview (in my opinion), hoping to bring some help to you

The structural pattern describes how classes or objects can be combined to achieve functionality. It is mainly divided into class structure pattern and object structure pattern. The class structure pattern adopts inheritance mechanism to organize interfaces and classes, and the object structure pattern adopts combination or aggregation to combine objects.

Back to the beginning, why do we use design patterns? It is well understood that design patterns are the crystallization of previous experience, each design pattern solves a specific problem, using these design patterns is standing on the shoulders of predecessors. For example, in object-oriented, singleton pattern can effectively solve the problem of repeated instantiation of a class. For some classes in the system, only one instance is important. At the same time, design patterns greatly increase code reusability, maintainability, and readability. There are two things I hate most, first when colleagues don’t write comments and second when they write comments to code).

Structural modes are divided into the following 7 types:

Proxy mode: Provides a Proxy for an object to control access to that object. That is, a client indirectly accesses an object through a proxy to restrict, enhance, or modify some of its features. Adapter pattern: Converts the interface of one class into another interface that the customer expects, making classes that would otherwise not work together due to interface incompatibility work together. Bridge pattern: Separate the abstraction from the implementation so that they can vary independently. It is realized by using combinatorial relation instead of inheritance relation, thus reducing the coupling degree between abstraction and implementation of these two variable dimensions. Decorator pattern: Dynamically assign responsibility to an object, that is, add additional functionality to it. Facade pattern: Provides a consistent interface to multiple complex subsystems, making them more accessible. Flyweight pattern: Sharing techniques are used to efficiently support reuse of large numbers of fine-grained objects. Composite pattern: Groups objects into a tree-like hierarchy, giving users consistent access to individual and Composite objects.Copy the code

The bridge model

Because in fact, the proxy pattern and the adapter pattern we all know very well, usually encountered a lot of, so THIS time I especially from the bridge pattern to share with you, at the same time I am doing the work also used this pattern.

1, define,

Abstract and reality are separated, and combinatorial relation is used to replace inherited relation. Because combinatorial relation has lower coupling degree than inherited relation and meets the “principle of composite reuse”, it has greater flexibility.

  • advantages
    • Due to the separation of abstraction and implementation, scalability is strong
    • Implementation details are more transparent
    • Low coupling, can change the content of the concrete implementation class and the abstract extension class at will
  • disadvantages
    • Low readability, especially for the first time people need more time to understand, but understanding will make people unconsciously reduce notes (easy to understand)

2, implementation,

The Bridge pattern contains the following key roles.

Abstract role: Defines an abstract class and contains a reference to the implementation object. Extended Abstract role: Is a subclass of an abstract role that implements the business methods in the parent class and implements the business methods in the role through composite relationship calls. Implemented roles: Defines interfaces for implemented roles that can be invoked by extended abstract roles. Concrete implementation role: Provides the concrete implementation of the implementation role interface.Copy the code

Abstract characters versus extended Abstract charactersImplementative roles versus implementative roles

As can be seen from the inheritance diagram of the code, there is no occasional relationship between inheritance and implementation in the structure of the abstraction and implementation of the role, but by implementing the role and extending the abstraction of the role call.

Abstract role

The code here is one of my abstract roles. It mainly defines the flow of the entire method in the abstraction, which can be inherited and overridden in the extended abstract role, and the business method in the role can be implemented through the composition relation call.

@ Slf4j public abstract class CBHBCallAbstractTianJinComponent implements CBHBCallComponent {/ * * @ * * * request processing param obj *  @return */ @Override public Object dealData(Object obj) throws ServiceException { String id = ""; RequestBo requ; ResponseBo response = null; Try {//1, check id = this.checkParam(obj); log.info("cbhb checkParam id :{}, obj :{}", id, obj); Requ = this.buildParam(obj); log.info("cbhb buildParam id :{}, requestDto :{}", id, requ); / / 3, secondary check String checkResult. = CheckFieldUtil checkParam (requ); if (! CheckFieldUtil. SUCCESS. Equals (checkResult)) {throw new BizException (" parameter calibration failure "); } // 4, response = (ResponseBo) this.dosend (requ, id); } catch (BizException e) { log.error("cbhb xxxx userId:{} error :{}", id, e.getMessage()); this.dealCheckFail(e.getMessage(), id); throw e; } catch (Exception e1) { log.error(getMethodDesc(), id, e1.getMessage(), e1); this.dealCheckFail(e1.getMessage(), id); Throw new RuntimeException("userId:" + id + ", "+ this.getFundLogDesc() +" error "+ E1.getMessage (), e1); } if (this.dealResult(response, id)) {return this.dealSuccess(response, id); } else { return this.dealFail(response, id); }} / * @ * * * to check incoming parameters param obj * @ return * / public String checkParam (Object obj) {if (Objects. IsNull (obj)) {throw New BizException(" Parameter null "); } return "userId"; } /** * @param userId */ public void dealCheckFail(String content, String userid) { log.error(this.getMethodDesc(), userid, content); throw new ServiceException(content); } public RequestBo buildParam(Object Object); /** @request * @return */ public ResponseBo doSend(RequestBo requ, String userId); ** @param resp * @return */ public Boolean dealResult(ResponseBo resp, String userid) { log.info("cbhb request ReqJnlNo {}, desc {}", resp.getReqJnlNo(), resp.getResMsg()); . ** @param resp * @return */ public Object dealSuccess(ResponseBo resp, String userid) { log.info(getMethodDesc(), userid, "success"); return resp; } @param resp * @return */ public Object dealFail(ResponseBo resp, String userid) { log.warn(getMethodDesc(), userid, resp.getResCode()); throw new ServiceException(resp.getResMsg()); } ** @return */ public String getMethodDesc() {return "XXXX request userId {}, desc {}"; } /** * @return */ public String getFundLogDesc() {return "XXXX "; }Copy the code

Extend abstract roles

Basic implementation of the parent class method, specific method specific analysis, can be unlimited extension, such as my side of these classes have been extended to the parent class method.(The code that is running and will be running should still be kept secret, only the custom code will be shared)

Implement roles concretely

This is a normal method in a service

    public boolean loan(LoanBo loanBo) {
        CreditDto creditDto = creditService.findByUserId(loanBo.getUserId());
        loanBo.setApplId(creditDto.getApplId());
        try {
            cbhbLoanComponent.dealData(loanBo);
        } catch (ServiceException e) {
            throw e;
        }
        return true;
    }
Copy the code

Implement roles

/** * loanBo * @param loanBo * @return */ Boolean Loan (loanBo loanBo);Copy the code

My example demonstrates the bridge pattern. If I need to extend a new feature, I only need to extend the implementation role, the concrete implementation role and the abstract role. The new feature does not affect the implementation of the previous feature, and you can even reuse the abstract role content completely. Bridge mode is also a good implementation of open and close principle, substitution principle, dependency lead principle, synthetic reuse principle. But because of the number of interfaces and my laziness, the code violated the principle of single responsibility and interface isolation (interface bloat).

3. Bridge mode applies to scenarios

  • When a class has two independently varying dimensions and both dimensions need to be extended.
  • When a system does not want to use inheritance or the number of system classes increases dramatically because of multi-level inheritance.
  • When a system needs to add more flexibility between the abstract and embodied roles of the component.

Bridge pattern can be understood as A bridge, the bridge on the left for A, on the right side of the bridge to B, A, A1, A2, A3, etc., said three different parts of the bridge on the left, B, B1, B2, B3, said three different parts of the bridge on the right side, assuming that we should start from the left side of the bridge A B on the right side of the bridge, we can have multiple solutions, A1 and B1, A1 and B2, A1 to B3, A2 to B1 and so on. With bridge mode, we can extend AB freely.

conclusion

Haven’t written article for a long time, because busy (lazy), this period of time summed up some development experience, continue to share with you ~

If you need it, you can add it to my official account, where the latest articles will be found in the first time. You can also ask me for mind map

If you need a mind map, please feel free to contact me. After all, the more you share, the better!