preface

Before I get into design patterns, I must emphasize here that any use of design patterns is based on context, not design patterns for design patterns’ sake. This is a lot of people who learn design patterns have no correct understanding of, a lot of people can often see some design patterns to match some code, or some design patterns can be used to modify the code, such as before a lot of people like to use the strategy pattern to kill in the code if the else without brain, then the thought to write elegant code, The aftereffects of being overblogged really leave me speechless.

The idea is important: design patterns need to look at the context, not just the code.Copy the code

The body of the

With that out of the way, let’s move on to the delegate pattern, which isn’t really one of the 23 design patterns, but it’s still one of the most commonly used object-oriented design patterns. How to actually use, we can refer to the following example.

Delegation mode, literally, can be something like this, where I delegate the whole thing or part of the thing to someone else to do something specific, maybe it’s part of my chain, But when the complexity is high, or when someone else can handle it well (note that these are both cases), I can simply delegate it to someone else.

Let’s take a look at we mentioned in our previous articles spring uniform resource loading PathMatchingResourcePatternReslover this class here, because it implements ResourcePatternReslover this interface, ResourcePatternReslover also inherits ResourceLoader interface, so it must implement ResourceLoader getResource method, let’s see how it is implemented:

        @Override
    	public Resource getResource(String location) {
    	    return getResourceLoader().getResource(location);
    	}
Copy the code

Let’s look at the getResourceLoader method again:

        public ResourceLoader getResourceLoader() {
		return this.resourceLoader;
	}
Copy the code

Which is the enclosing resourceLoader, take a look at the structure of the PathMatchingResourcePatternReslover method:

        public PathMatchingResourcePatternResolver() {
		this.resourceLoader = new DefaultResourceLoader();
	}

	public PathMatchingResourcePatternResolver(ResourceLoader resourceLoader) {
		Assert.notNull(resourceLoader, "ResourceLoader must not be null");
		this.resourceLoader = resourceLoader;
	}
Copy the code

Believe that everyone has to see see, see here the getResource PathMatchingResourcePatternReslover is delegated to the resourceLoader to completely. There are many other places in Spring that use this, but I won’t list them all.

Let’s look at the code for the standard delegate mode:

public interface Target {
    void doSomeThing();
}
Copy the code
@Component
public class BDelegate implements Target {

    @Override
    public void doSomeThing() {
        System.out.println("B"); }}Copy the code
@Component
public class ADelegate implements Target {

    @Override
    public void doSomeThing() {
        System.out.println("A"); }}Copy the code
@Component
public class Boss implements Target{

    @Autowired
    private List<Target> targets;

    @Override
    public void doSomeThing(){ targets.forEach(Target::doSomeThing); }}Copy the code

A super simple example. To add a little bit of context, the Boss doesn’t have to implement the Target interface in practice. The logic in the Boss can also be very complex logic containing ADelegate or BDelegate, but the Boss doesn’t have to do the work itself and just gives it to the ADelegate and BDelegate classes.