Interface Isolation principle: Avoid change risk _ design pattern through design

What is the interface isolation principle?

Interface Isolation principle: The client should not rely on interfaces that it does not need, but instead build dependencies between classes on the smallest interface.

In other words, in actual development, the client needs what interface we provide it with and remove the unwanted interface. So there will be a problem: some interfaces cover more functions, our class in the implementation of the interface may only need to apply to some of the interface methods, then what to do? We should make the interface of the class as detailed as possible, and use what we need, instead of just greedy for "more". Why you need to rely on inverted principles

Let's play the game for example:

A game with a lot of elements, some of the UI is particularly good-looking, some of the action is particularly cool, a little story particularly interesting, and so on ...

Public interface Igame {public
    void Niceui ();

    public void Goodstory ();

    public void Coolaction ();

    public void Newplaymode ();

    There are many more
}

The game elements of different games are not the same, the characteristics of different games are not the same, for example:

Action class Games:

public class Actiongame implements Igame {

    @Override public
    void Niceui () {
        System.out.println ("Gorgeous UI");
    }

    @Override public
    void Goodstory () {
        System.out.println ("Story General");
    }

    @Override public
    void Coolaction () {
        System.out.println ("Cool Action");
    }

    @Override public
    void Newplaymode () {
        System.out.println ("game mode General");
    }

Story class games:

public class Storygame implements igame{

    @Override
    the public void Niceui () {
        System.out.println ("UI small freshness");
    }

    @Override public
    void Goodstory () {
        System.out.println ("Interesting Story");
    }

    @Override public
    void Coolaction () {
        System.out.println (action General);
    }

    @Override public
    void Newplaymode () {
        System.out.println ("game mode New");
    }

At first glance this is no problem, think about it, some game enthusiasts think action games also need to consider the degree of freedom of play, then we in order to meet this demand, we have to add a method in the Igame interface. After adding the method, the Storygame class also has to change, but Storygame does not need to consider the degree of freedom of the game ah, why to affect the Storygame class. In the same way, if game enthusiasts say story-like games need to consider whether the characters ' movements and scenes are delicate and real, and this is not necessary in the action class, why do we have to change the Actiongame class? So we'll find that the Igame interface is really "too big" and we need to refine it:

Public interface IUI {public
    void Niceui ();
}

Public interface IAction {public
    void coolaction ();
}

Public interface Istory {public
    void goodstory ();
}

Public interface Iplaymode {public
    void Newplaymode ();
}

Through this subdivision interface, let our game class need what interface to implement what interface, when need to modify only the specific interface, maintain the stability of the interface, improve the flexibility and maintainability of the system. Ensure interface purity interface to be as small as possible interface design is a limited practical application of an interface to serve only a child module or business logic through the business logic compression interface of the public method has been contaminated the interface as far as possible to modify, if the risk of change is greater, The adapter mode is used to transform the process to understand the environment and reject the design of others blindly