More excellent articles.
“Microservices are not all, just a subset of a specific domain”
Selection and process should be careful, otherwise it will be out of control.
Out of all the monitoring components, there’s always one for you
What are we Developing with Netty?
This is probably the most pertinent Redis specification
Portrait of a Programmer: A Decade of Ups and Downs
Most useful series:
The Most Common Set of “Vim” Techniques for Linux Production
The most Common set of “Sed” Techniques for Linux Production
The Most Common Set of “AWK” Tips for Linux Production
If you agree with this knowledge, welcome to follow the wechat public account Xiaojie Taste
ID: xjjdog
Factory method pattern
Spring provides the FactoryBean interface for creating a variety of beans.
Developers can also implement this interface themselves, often for framework integration. Such is the case with SqlSessionFactoryBean.
Template method pattern
Spring for JDBC, JMS, JPA specification, provides the corresponding template method, such as JdbcTemplate, JmsTemplate, JpaTemplate. For example, JdbcTemplate provides many common add, delete, query, and modify method templates. JMSTemplate provides methods for sending and receiving messages. Below is a partial method diagram of JMSTemplate
The proxy pattern
Spring AOP, transactions, and so on all make extensive use of the proxy pattern.
Observer model
Spring provides an event listener mechanism, called ApplicationListener, to implement event listening in the Spring container.
There are two main interfaces: Publish messages
Listen to the message
The singleton pattern
Spring’s default scope for creating beans is a singleton, meaning that only one instance of the class exists per Spring container. This can be modified to prototype mode via @Scope(” Prototype “), which is called prototype mode in design mode. In fact, Spring’s handling of beans labeled by @Scope(” Prototype “) is prototype mode.
The prototype pattern
The prototype pattern is a type of creation pattern that is characterized by “copying” an existing instance to return a new one, rather than creating a new one. The copied instance is what we call a “prototype,” which is customizable. The prototype pattern is often used to create complex or time-consuming instances, because copying an existing instance makes the application run more efficiently. Or create identical data with different names.
In Spring, if a class is marked “prototype,” each request (to inject it into another bean, or programmatically call the container’s getBean() method) generates a new bean instance. However,Spring is not responsible for the entire life cycle of a Prototype Bean; the container initializes, configures, decorates, or assembs a Prototype instance, hands it to the client, and then does nothing about it. Regardless of scope, the container calls the initialization life cycle callback methods of all objects, and for Prototype, any configured destructor life cycle callback methods will not be called. It is the client code’s responsibility to clean up prototype-scoped objects and free up any expensive resources held by prototype beans.
Chain of Responsibility model
In SpringMVC, we often use handlerInterceptors. When there are multiple interceptors, all of them form a chain of interceptors. The HandlerExecutionChain class is used in SpringMVC to assemble all interceptors together. Note that the return value of the preHandle method is a Boolean type, which determines whether the next interceptor should continue processing.
The article of my old address: blog.leanote.com/post/medusa…
