Design Practice mode - mode of appearance

What is the appearance of the model? When to use?

Appearance mode, also called facade mode. In fact, in everyday life, there are many shadow appearance models, such as our daily work, leadership, decided to develop a broadcast module, the leadership issue commands to the middle (department boss), the middle is assigned to a specific execution layer (we have developed ). Leaders do not need to know how the following people are assigned, and who with, just make an order acceptance can be the result.

Scenes

  • Such as changing the studio just completed module, user roles, many parts of the state on the UI interface, style, and so need to switch the click event, this article will not list them, not the focus of this article, to avoid beside the point.

  • There are studio the following roles:

    1. general user
    2. Theravada user
    3. Housing management
    4. Teacher (anchor)
    5. Gag user
    6. Tourist
1641428-684fb19a0e76a6d4.png
Studio style .png
  • We can see the role between live very much, does not rule out the future will add other roles, such as other pk, help teachers and other fields. This relates to the role switching, where switching and more than one, some switching from the interface when the callback is invoked, some IM trigger switches and so on ... it is greater than the component to be switched more than 3, each will need to write at the same code, and follow along with the components also need to switch when you need to be at each modification, then you can use the skin to unify distributed mode switch, external caller without having to know which components need to be switched, only need to initiate a handover of action behavior can be.

How to achieve the appearance mode?

  • Facade, facade interfaces, external interfaces provided by Api.
  • Subsystem interface, each subsystem needs to implement.

Appearance practice mode, unified treatment studio roles change

If the normal logic to write our code, there will be a lot of if-else, so I have every UI component package again with state mode, external only need to call the API to switch roles, is how the internal switch need not concern , is to show, hide or Remove, Add. The role change is not only an opportunity, then switching method invocation of the various components will be everywhere, in order to solve this case we use the appearance model, unified call appearance, appearance and then distributed to each of the components required to switch roles.

Implementation steps

  1. IRoleSwitcher interfaces, role switching interface that defines the role of each switching method, where due to the operation of our facade and other components are the same, so the merger to an interface.

  2. Component interface subsystem interface, define a general assembly method, each subsystem will it have an interface to inherit it, and provide specific Api subsystem.

  3. IBottomBarComponent, bottom bar component interfaces, implements the Component interface and IRoleSwitcher interface.

  4. IApplyForSeatComponent, Theravada button component interfaces, and implements the Component interface IRoleSwitcher interface.

  5. IToolBoxComponent, Sidebar component interfaces, implements the Component interface and IRoleSwitcher interface.

  6. IRoleComponent, the role of the components that we look, Facade, responsible for the distribution switch event to the above three components and subsystems because we facade Api Api is the same, it itself implements IRoleSwitcher user interface. Component also achieved as a component use. (Non-essential, but our scenario is relatively simple, basic is distributed switching events, while others require different subsystems with scenes facade Api general and subsystems are not the same)

Do nonsense, the code ~

  • Component Component Interface and IRoleSwitcher interface.
public interface Component {
}

public interface IRoleSwitcher {
    /**
     * 设置为普通用户角色
     */
    void setNormalUserRole();

    /**
     * 设置为管理员角色
     */
    void setManagerRole();

    /**
     * 设置为上座用户角色
     */
    void setSeatUpRole();

    /**
     * 设置为老师角色
     */
    void setTeacherRole();

    /**
     * 设置为游客角色
     */
    void setVisitorRole();

    /**
     * 设置为游客禁言角色
     */
    void setForbidSpeakRole();
}
  • IBottomBarComponent, bottom bar assembly interface and implementation class
public interface IBottomBarComponent extends Component, IRoleSwitcher {
    //...其他Api方法,不是重点
}

public class BottomBarComponent extends BaseRoomComponent implements IBottomBarComponent {
    @Override
    public void setNormalUserRole() {
        //底部栏切换到普通用户角色样式
        ...
    }

    @Override
    public void setManagerRole() {
        //底部栏切换到普通用户角色样式
        ...
    }

    @Override
    public void setSeatUpRole() {
        //底部栏切换到上座用户角色样式
        ...
    }

    @Override
    public void setTeacherRole() {
        //底部栏切换到老师用户角色样式
        ...
    }

    @Override
    public void setVisitorRole() {
        //底部栏切换到游客角色样式
        ...
    }

    @Override
    public void setForbidSpeakRole() {
        //底部栏切换到禁言用户角色样式
        ...
    }
}
  • IApplyForSeatComponent, Theravada button assembly
public interface IApplyForSeatComponent extends Component, IRoleSwitcher {
        //...省略其他Api
}

public class ApplyForSeatComponent extends BaseRoomComponent implements IApplyForSeatComponent {
        //...实现方法和BottomBarComponent是一致的,所以不再列举
}
  • IToolBoxComponent, Sidebar Components
public interface IToolBoxComponent extends Component, IRoleSwitcher {
        //...省略其他Api
}

public class ToolBoxComponent extends BaseRoomComponent implements IToolBoxComponent {
        //...实现方法和BottomBarComponent是一致的,所以不再列举
}
  • IRoleComponent, the role of components, intermediate class
public class RoleComponent extends BaseRoomComponent implements IRoleComponent {
@Override
    public void setNormalUserRole() {
        getComponentProvider().getBottomBarComponent().setNormalUserRole();
        getComponentProvider().getApplyForSeatComponent().setNormalUserRole();
        getComponentProvider().getToolBoxComponent().setNormalUserRole();
    }

    @Override
    public void setManagerRole() {
        getComponentProvider().getBottomBarComponent().setManagerRole();
        getComponentProvider().getApplyForSeatComponent().setManagerRole();
        getComponentProvider().getToolBoxComponent().setManagerRole();
    }

    @Override
    public void setSeatUpRole() {
        getComponentProvider().getBottomBarComponent().setSeatUpRole();
        getComponentProvider().getApplyForSeatComponent().setSeatUpRole();
        getComponentProvider().getToolBoxComponent().setSeatUpRole();
    }

    @Override
    public void setTeacherRole() {
        getComponentProvider().getBottomBarComponent().setTeacherRole();
        getComponentProvider().getApplyForSeatComponent().setTeacherRole();
        getComponentProvider().getToolBoxComponent().setTeacherRole();
    }

    @Override
    public void setVisitorRole() {
        getComponentProvider().getBottomBarComponent().setVisitorRole();
        getComponentProvider().getApplyForSeatComponent().setVisitorRole();
        getComponentProvider().getToolBoxComponent().setVisitorRole();
    }

    @Override
    public void setForbidSpeakRole() {
        getComponentProvider().getBottomBarComponent().setForbidSpeakRole();
        getComponentProvider().getApplyForSeatComponent().setForbidSpeakRole();
        getComponentProvider().getToolBoxComponent().setForbidSpeakRole();
    }
}
  • Switching calls at call
mDataStore = getDataStore();
    
//监听房间信息改变切换角色。
mDataStore.getLiveRoomViewModel().getRoomInformationLiveData().observe(getLifecycleOwner(), new Observer<RoomInformationModel>() {
@Override
public void onChanged(@Nullable RoomInformationModel roomInformationModel) {
    if (roomInformationModel == null) {
        return;
    }
    IMRoomInfoModel roomInfoModel = roomInformationModel.getRoomInfo();
    IMSendUserModel currentUser = mDataStore.getLiveRoomViewModel().getCurrentUserLiveData().getValue();
    if (currentUser == null) {
        return;
    }
    //这里简单期间,省略了决定角色的生成,决定后通知其他组件切换样式
    IRoleComponent roleComponent = getComponentProvider().getRoleComponent();
    //老师角色
    if (currentUser.isTeacher()) {
        roleComponent.setTeacherRole();
    } else if (currentUser.isNormalUser()) {
        //普通用户角色
        roleComponent.setNormalUserRole();
    } else if (currentUser.isSeatUpUser()) {
        //上座用户角色
        roleComponent.setSeatUpRole();
    } else if (currentUser.VisitorRole()) {
        //游客角色
        roleComponent.setVisitorRole();
    } else if (currentUser.isForbidSpeakUser()) {
        //禁言用户角色
        roleComponent.setForbidSpeakRole();
    }
}
});

to sum up

  • Appearance Model advantages: to provide a unified method of external entry, hiding the details of the internal subsystem.

  • Shortcoming appearance model, the appearance of the class did not follow the principle of opening and closing, when our business changes, you may need to modify the appearance of the class, adding new logic and sub-classes.

Reproduced in: https: //www.jianshu.com/p/75d9b9b2cd6c

Guess you like

Origin blog.csdn.net/weixin_33910137/article/details/91135594