Java - 从Interface类型而不是Class声明 [英] Java - declaring from Interface type instead of Class

查看:157
本文介绍了Java - 从Interface类型而不是Class声明的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

为了正确掌握界面最佳实践,我注意到了以下声明:

In my quest to correctly grasp Interface best practices, I have noticed declarations such as:

List<String> myList = new ArrayList<String>();

而不是

ArrayList<String> myList = new ArrayList<String>();

- 我的理解是因为它允许灵活性,以防有一天你不想实施一个ArrayList但也许是另一种类型的列表。

-To my understanding the reason is because it allows flexibility in case one day you do not want to implement an ArrayList but maybe another type of list.

通过这个逻辑,我设置了一个例子:

With this logic, I set up an example:

public class InterfaceTest {

    public static void main(String[] args) {

        PetInterface p = new Cat();
        p.talk();

    }

}

interface PetInterface {                

    public void talk();

}

class Dog implements PetInterface {

    @Override
    public void talk() {
        System.out.println("Bark!");
    }

}

class Cat implements PetInterface {

    @Override
    public void talk() {
        System.out.println("Meow!");
    }

    public void batheSelf() {
        System.out.println("Cat bathing");
    }

}

我的问题是,我无法访问batheSelf()方法,因为它仅适用于Cat。这让我相信我只应该从接口声明我是否只会使用接口中声明的方法(而不是子类中的额外方法),否则我应该直接从类声明(在本例中为Cat)。我在这个假设中是否正确?

My question is, I cannot access the batheSelf() method because it only exists for Cat. That leads me to believe that I should only declare from an Interface if I am only going to use methods declared in the Interface (and not extra methods from the subclass), otherwise I should declare from the Class directly (in this case Cat). Am I correct in this assumption?

推荐答案

当通过引用对象之间有选择时接口,前者应该是首选,但只有在存在适当的类型时

When there is a choice between referring to an object by their interface or a class, the former should be preferred, but only if an appropriate type exists.

考虑 String implements CharSequence 为例。对于所有情况,你不应该盲目地使用 CharSequence 来优先选择字符串,因为这会让你无视简单的操作,比如 trim() toUpperCase()

Consider StringimplementsCharSequence as an example. You should not just blindly use CharSequence in preferrence to String for all cases, because that would deny you simple operations like trim(), toUpperCase(), etc.

但是,只需要关注 char 序列的 String 的方法使用 CharSequence 代替,因为在这种情况下这是合适的类型。这实际上就是 字符串 c> class。

However, a method that takes a String only to care about its sequence of char values should use CharSequence instead, because that is the appropriate type in this case. This is in fact the case with replace(CharSequence target, CharSequence replacement) in the String class.

另一个例子是 java.util.regex.Pattern 及其 Matcher matcher(CharSequence) 方法。这样就可以从 Pattern 创建一个 Matcher ,而不仅仅是 String ,但也适用于所有其他 CharSequence 那里有。

Another example is java.util.regex.Pattern and its Matcher matcher(CharSequence) method. This lets a Matcher be created from Pattern for not just String, but also for all other CharSequence there are out there.

图书馆中的一个很好的例子接口应该已经使用过,但遗憾的是,也可以在 Matcher appendReplacement appendTail 方法仅接受 StringBuffer 。这个类很大程度上被它的表兄弟 <$ c自1.5以来$ c> StringBuilder

A great example in the library of where an interface should've been used, but unfortunately wasn't, can also be found in Matcher: its appendReplacement and appendTail methods accept only StringBuffer. This class has largely been replaced by its faster cousin StringBuilder since 1.5.

A StringBuilder 不是一个 StringBuffer ,所以我们不能在 Matcher <中使用 append ... 方法使用前者/ code>。但是,它们都是实现 可附加 (也在1.5中引入)。理想情况下匹配追加... 方法应该接受任何可附加 ,然后我们就可以使用 StringBuilder ,以及所有其他可附加可用!

A StringBuilder is not a StringBuffer, so we can not use the former with the append… methods in Matcher. However, both of them implementsAppendable (also introduced in 1.5). Ideally Matcher's append… method should accept any Appendable, and we would then be able to use StringBuilder, as well as all other Appendable available!

因此我们可以看到当适当的类型存在时通过它们的接口引用对象可以是一个强大的抽象,但只有当这些类型存在时。如果类型不存在,那么如果有意义,您可以考虑定义自己的类型。在此 Cat 示例中,您可以定义接口SelfBathable 。然后,您可以接受任何 SelfBathable 对象(例如 Parakeet),而不是引用 Cat

So we can see how when an appropriate type exists referring to objects by their interfaces can be a powerful abstraction, but only if those types exist. If the type does not exist, then you may consider defining one of your own if it makes sense. In this Cat example, you may define interface SelfBathable, for example. Then instead of referring to a Cat, you can accept any SelfBathable object (e.g. a Parakeet)

如果创建新类型没有意义,那么无论如何都可以通过<$ c $来引用它c> class

If it does not make sense to create a new type, then by all means you can refer to it by its class.


  • Effective Java 2nd Edition,Item 52:通过接口引用对象

  • Effective Java 2nd Edition, Item 52: Refer to objects by their interfaces

如果存在适当的接口类型,则参数,返回值和字段都应该使用接口类型声明。如果您养成使用界面类型的习惯,您的程序将更加灵活。如果没有合适的接口,则通过类引用对象是完全合适的。

If appropriate interface types exist, then parameters, return values, and fields should all be declared using interface types. If you get into the habit of using interface types, your program will be much more flexible. It is entirely appropriate to refer to an object by a class if no appropriate interface exists.


  • Bug ID: 5066679 - java.util.regex.Matcher should make more use of Appendable

这篇关于Java - 从Interface类型而不是Class声明的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆