简体   繁体   中英

Java - Choosing the design pattern - 2 interfaces with same methods, except one has an extra parameter

So I have 2 interfaces (show below), 1 for regular/free kits and another one for purchasable kits. They both contain 2 methods, but in the "getIcon" method for purchasable kits, I need the player's profile as a parameter so I can check if they have bought the kit.

What is the best design pattern to use to link these 2 interfaces? and can you possibly show me the code to do it?

The 2 interfaces:

public interface Kits {

    void giveKit(Player player);

    Item getIcon();
}


public interface PurchasableKits {

    void giveKit(Player player);

    Item getIcon(Profile profile);
}

I attempted to use the adapter pattern but it doesn't seem right because the "getIcon" method is taking in a profile as a parameter but it doesn't get used.

public class KitAdapter implements PurchasableKits {

    private Kits kits;

    public KitAdapter(Kits kits) {
        this.kits = kits;
    }

    @Override
    public void givetKit(Player player){
        kits.giveKit(player);
    }

    @Override
    public void getIcon(Profile profile){
        kits.getIcon();
    }

}

Thanks in advance

You have 1 interface PurchasableKits . A free Kit would implement the interface and call getIcon(null) .

The red flag is that the 2 interfaces are almost exactly the same. No design pattern will get you out of the situation that creates.

That's a tricky question because of the rules of the inheritance and cyclic inheritance avoided in java.

I don't believe that you need to interfaces, you could do something like this:

public interface Kits {

    void giveKit(Player player);

    //a vargars usage
    Item getIcon(Profile... p);
}

public class ConcreteClass implements Kits{

    @Override
    public void giveKit(Player player) {
        // TODO Auto-generated method stub

    }

    @Override
    public Item getIcon(Profile... o) {
        //This is the ugly thing of this method. You must check the sent params. 
        //However I think it is better than send a null param, as the clean code suggest to avoid
        if(o.length == 0)
            System.out.println("without profile");
        else
            System.out.println("With profile");
        return null;
    }

}

public class Main {

    public static void main(String[] args) {
        ConcreteClass my = new ConcreteClass();
        my.getIcon();
        my.getIcon(new Profile());
    }
}

The output: without profile With profile

So I have 2 interfaces (show below), 1 for regular/free kits and another one for purchasable kits. They both contain 2 methods, but in the "getIcon" method for purchasable kits, I need the player's profile as a parameter so I can check if they have bought the kit.

Whether or not the profile is needed in the getIcon(...) method is an implementation detail of those Kit s that are purchasable. I would just have a Kit interface that has the following definition:

public interface Kit {
    void giveKit(Player player);
    Item getIcon(Profile profile);
}

So every time you wanted to get the icon you would pass in the Profile and it would be up to the kits that are purchasable to look at the profile. The free ones would just ignore the argument. That you sometimes pass in null and sometimes not means that you know beforehand whether or not it is free which means that something is wrong with your model.

Couple of other comments about your code. Just my opinions:

  • Concrete classes tend to be nouns. Interfaces tend to be verbs. Maybe KitHandler instead of Kit ?
  • Class names tend to be singular so then you can put them in a list. Maybe Kit (or KitHandler ) would be better so you can create a List<Kit> kits = ... .
  • I used get methods to return fields which means that they typically don't take arguments. Maybe getIcon should be generateIcon(...) ?

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM