This is the 17th day of my participation in Gwen Challenge

The mediator pattern

The mediator pattern can also be called the mediator pattern or the mediator pattern.

Mediator definition: The mediator pattern wraps the way in which a series of objects interact so that there is no obvious need for them to interact with each other, resulting in loose coupling. Changes in the roles between objects do not immediately affect the roles between other objects. The mediator pattern transforms the original many-to-many interactions into one-to-many interactions.

In actual combat

In the mediator pattern, the mediator has always been the role of coordinating the interactions between multiple objects. The MainBoard is the intermediary to establish a relationship between each part in the computer. Each part holds all MainBoard objects. After the MainBoard is initialized, the Mediator change method will be called when a part needs to be executed. In the MainBoard process, the MainBoard will determine which part is involved in the invocation and execute the corresponding method. In this way, the function required by corresponding parts was performed by Mediator, decoupling the relationship between parts and parts.

// Abstract mediator
public abstract class Mediator {
    public abstract void change(Colleague c);
}

// Specific intermediaries
public class MainBoard extends Mediator {
    private CPU cpu;
    private SoundCard soundCard;
    private GraphicsCard graphicsCard;
    
    @override
    public void change(Colleague c) {
        if(c == cpu){
            handleCPU((CPU)c);
        }else if(c == graphicsCard){ handleGraphicsCard((GraphicsCard)c); }}private void handleCPU(CPU cpu){
        soundCard.soundPlay(cou.getDataSound());
        graphicsCard.videoPlay(cou.getDataVideo());
    }
    private void handleGraphicsCard(GraphicsCard graphicsCard){
        cpu.getInfo(graphicsCard.getDataInfo());
    }
    public void setCPU(CPU cpu){
        this.cpu = cpu;
    }
    public void setSoundCard(SoundCard SoundCard){
        this.soundCard = soundCard;
    }
    public void setGraphicsCard(GraphicsCard graphicsCard){
        this.graphicsCard = graphicsCard; }}// Abstract colleague class
abstract class Colleague {
    protected Mediator mediator;
    public Colleague(Mediator mediator){
        this.mediator = mediator; }}// Specific colleague class
class CPU extends Colleague {
    public CPU(Mediator mediator) {
       super(mediator)
    }
    public void getInfo(a);
    public void getDataSound(a);
    public void videoPlay(a);
    
    public void load(a){
     mediator.load(this); }}class SoundCard extends Colleague {
    public SoundCard(Mediator mediator) {
       super(mediator)
    }
    public void soundPlay(a);
}

class GraphicsCard extends Colleague {
    public GraphicsCard(Mediator mediator) {
       super(mediator)
    }
    public void videoPlay(a);
}

/ / execution
MainBoard mainBoard = new MainBoard();

CPU cpu = new CPU();
SoundCard soundCard = new SoundCard();
GraphicsCard graphicsCard = new GraphicsCard();

mainBoard.setCPU(cpu);
mainBoard.setSoundCard(soundCard);
mainBoard.setGraphicsCard(graphicsCard);


Copy the code

conclusion

In programming, a class inevitably has dependencies on other classes. If this relationship is too complex to be removed, it will inevitably affect later development extensions and code logic. Appropriate use of the mediator pattern can decouple this dependency and make the logical structure of your code clear.

reference

  • The mediator pattern
  • Android Source Code Design Patterns