简体   繁体   English

Java - 允许实现指定参数列表的接口

[英]Java - Interface to allow implementations to specify parameter list

I have this case where I want to implement a suggestion service.我有这种情况,我想实施建议服务。 This is supposed to be a service that users can call to retrieve suggestive values for certain, defined fields.这应该是一种服务,用户可以调用它来检索某些已定义字段的建议值。 Say I want a suggestions for a car and mobilephones.假设我想要关于汽车和手机的建议。 These fields are fixed and I can thus hardcode a method for each in the interface of the service.这些字段是固定的,因此我可以在服务接口中为每个字段硬编码一个方法。

However, the implementation of the actual service should be free to determine how it retrieves these suggestion.但是,实际服务的实现应该可以自由地确定它如何检索这些建议。 It might look into a file, it might call a webservice, whatever.它可能会查看一个文件,它可能会调用一个 Web 服务,等等。 For that, it should also be able to determine what parameters it needs to retrieve these suggestions.为此,它还应该能够确定检索这些建议所需的参数。 Some implementations might want more information, some might want less.有些实现可能需要更多信息,有些可能需要更少。 The same for what it returns: Some implementations might return a single value, others multiple.它返回的内容相同:某些实现可能返回单个值,而其他实现可能返回多个。

I want to reflect this in the interface of the service, so I write it like this:我想在服务的界面中体现这一点,所以我这样写:

public interface SuggestionService {
    SuggestionResult getCarSuggestion(final SuggestionCriteria criteria);
    SuggestionResult getMobilephoneSuggestion(final SuggestionCriteria criteria);
}

Both SuggestionResult and SuggestionCriteria are interfaces. SuggestionResultSuggestionCriteria都是接口。 Implementations of the SuggestionService can use their own implementations of these two interfaces to properly provide the functionality. SuggestionService的实现可以使用他们自己的这两个接口的实现来正确地提供功能。 This works very fine for return types, as I am allowed to narrow them in my method-implementations:这对于返回类型非常有效,因为我可以在我的方法实现中缩小它们:

public class SuggestionServiceImpl implements SuggestionService {
    public CarSuggestionResult getCarSuggestion(final SuggestionCriteria criteria) {...}
    public MobilephoneSuggestionResult getMobilephoneSuggestion(final SuggestionCriteria criteria) {...}
}

The problem is that I cannot change the parameter type.问题是我无法更改参数类型。 If I do this in SuggestionServiceImpl如果我在SuggestionServiceImpl中这样做

public CarSuggestionResult getCarSuggestion(final CarSuggestionCriteria criteria) {...}

Then I get a compile error.然后我得到一个编译错误。 Which makes sense because I have now narrowed the interface that I am trying to implement by reducing the amount of allowed parameter-types.这是有道理的,因为我现在通过减少允许的参数类型的数量来缩小我试图实现的接口。 This is, for good reasons, not allowed.出于充分的理由,这是不允许的。

However, I feel like the SuggestionServiceImpl should be able to tell users of it what parameters it actually needs - by specifying them in it's method signature.但是,我觉得SuggestionServiceImpl应该能够告诉用户它实际需要哪些参数——通过在它的方法签名中指定它们。 There is a weird conflict of interest here and I can't come up with a solution to solve this.这里有一个奇怪的利益冲突,我无法想出解决这个问题的解决方案。 One the one hand, I want to write and use an interface that actual implementations needs to implement.一方面,我想编写和使用实际实现需要实现的接口。 This way I can make sure that all implementations provide methods for retrieving the fields that I am interested in - in this case car and mobilephone.通过这种方式,我可以确保所有实现都提供检索我感兴趣的字段的方法——在本例中为汽车和手机。 However, the implementations interface should be able to tell it's users exactly what parameters of what type it needs and not accept any generic list of parameters, putting it on the user to pass the correct ones.但是,实现接口应该能够准确地告诉用户它需要什么类型的参数,并且不接受任何通用参数列表,让用户传递正确的参数。 Is there any way to combine these two desires?有没有办法把这两种欲望结合起来?

The signature is still an interface, there is no requirement for them to all be homogenised into similar looking calls when they are not.签名仍然是一个接口,没有要求它们都被同质化为看起来相似的调用。

public interface CarSuggester {
    Car getCarSuggestion(String param1);
}

public interface PhoneSuggester {
    List<Phone> getPhoneSuggestion(int param1, String param2);
}

public class SuggestionService implements CarSuggester, PhoneSuggester {
    ...
}

This let's you keep (and test) discrete suggesters with a simple Facade Pattern to roll them together into a single impl (up to you if you require discrete impls as well - suggest it might well be sensible)这让您可以使用简单的 Facade Pattern 保留(并测试)离散的建议器,以将它们组合成一个 impl(如果您也需要离散的 impl,则由您决定 - 建议它可能是明智的)

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

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