This is the 25th day of my participation in the August Challenge

1. Inventory management

Almost all enterprises are inseparable from the “purchase, sale and inventory management” system, which is divided into three modules: procurement, sales and inventory.

1. Procurement: responsible for the procurement of products, depending on the sales module, according to the sales situation of products, more procurement, poor procurement.
2. Sales: Responsible for selling products, relying on inventory and procurement, notify procurement when there is no stock to sell.
3. Inventory: responsible for providing the inventory of products, if a product can not be sold and overstocked, it is necessary to inform the procurement module to stop purchasing, inform the sales module to discount processing.

It can be seen that the three modules are interdependent and coupled, as shown in the diagram below:Let’s try to implement the system in code, first drawing the class diagram: procurement

class Purchase {
    Stock stock;
    Sale sale;

    void buy(a){
        if (sale.isActiveDemand()) {
            // Sell well, buy more goods
            stock.change(100);
        }else {
            // Slow sales, less stock
            stock.change(10); }}void stop(a){
        print("Stop purchasing..."); }}Copy the code

sales

class Sale {
    Purchase purchase;
    Stock stock;

    // Does it sell well
    boolean isActiveDemand(a){
        return true;
    }

    // Normal sales
    void sell(a){
        stock.decrease(1);
        if (stock.getAmount() <= 0) {
            // We are out of stockpurchase.buy(); }}// At a discount
    void discountSell(a){
        print("On sale while stock lasts...");
        stock.decrease(1); }}Copy the code

inventory

class Stock {
    Purchase purchase;
    Sale sale;

    // Change inventory
    void change(int num) {
        print("Inventory change :" + this.amount);
    }

    // Inventory clearance
    void clearStock(a) {
        / / poor
        // Stop purchasing
        purchase.stop();
        // Clearance processing, discount salesale.discountSell(); }}Copy the code

Functionality is fine, but what are the problems with this implementation?

1. The coupling is so strong that classes depend on each other, and any change to one class can affect other classes.
2. There are too many friend classes, and the class needs to communicate with too many friend classes to complete a function.
3. The dependencies between classes are a network structure, and adding a friend class would require a lot of code modification.

Try to optimize this structure using design patterns. Can we optimize the mesh structure into a star structure? As follows:Add an intermediary class. Each colleague class only cares about its own business logic, and everything that needs to deal with other colleague classes will be completed through the intermediary. The optimized class diagram is as follows: Mediators

@Setter
class Mediator {
    // The mediator depends on all objects
    Purchase purchase;
    Sale sale;
    Stock  stock;

    / / purchase
    void buy(a){
        if (sale.isActiveDemand()) {
            // Sell well, buy more goods
            stock.increase(100);
        }else {
            // Slow sales, less stock
            stock.increase(10); }}// omit other methods
}
Copy the code

A Colleague class is an abstract Colleague class. All Colleague classes rely on the intermediary object:

abstract class Colleague {
    protected Mediator mediator;
}
Copy the code

procurement

class Purchase extends Colleague{

    void buy(a){
        // If you need to rely on other colleague classes, let the broker handle itmediator.buy(); }}Copy the code

Same with the sales class and the inventory class, there is no code attached here.

The optimized colleague class becomes very simple and clear. This is the mediator pattern!

2. Definition of the mediator pattern

By encapsulating a set of object interactions with a mediation object, the mediator loosens the coupling by allowing objects to interact without explicitly, and can change their interactions independently.

Generic class diagram for the Mediator pattern

There are two methods of the colleague class, spontaneous methods that handle their own business logic, and dependent methods that rely on intermediaries to do so.

3. Advantages and disadvantages of the intermediary model

advantages

1. The dependency between classes is reduced, and the original one-to-many dependency is optimized to one-to-one dependency. All colleague classes will not depend on each other, but only rely on the intermediary class, reducing the coupling.
2. By optimizing the network structure into a star structure, the colleague class becomes very stable.
3. The responsibilities of the class become clearer.

disadvantages

1. An exception to the mediation class affects all colleague classes.
2. As the number of colleague classes increases, intermediaries grow very large and become very complex.

4. To summarize

The mediator pattern increases the number of mediator classes and complicates the system structure. There is no need to use the mediator pattern if you are dealing with simple dependencies of a few classes. Remember, don’t use design patterns just for the sake of using them. The mediator pattern applies when there is tight coupling between multiple classes. What is “tight coupling”? The simplest way to tell is that the relationships between classes are “netted”. Mediator pattern is also called “mediator model”, if N objects need to communicate with each other, then the relationship between objects can become very complex, as the object of war, by adding a mediation, all objects only communicate with the mediation, the mediation out forward your appeal again, will become clear structure of between objects, such as independent.