Java - 从接口类型而不是类声明 [英] Java - declaring from Interface type instead of Class
问题描述
在我寻求正确掌握界面最佳实践的过程中，我注意到了如下声明:
ListmyList = new ArrayList(); 代替
ArrayListmyList = new ArrayList(); -据我所知，原因是它允许灵活，以防有一天您不想实现 ArrayList 而可能是另一种类型的列表.
按照这个逻辑，我设置了一个例子:
public class InterfaceTest {公共静态无效主(字符串 [] args){PetInterface p = new Cat();p.talk();}}接口宠物接口{公共无效谈话()；}类 Dog 实现 PetInterface {@覆盖公共无效谈话(){System.out.println("吠叫！");}}类 Cat 实现了 PetInterface {@覆盖公共无效谈话(){System.out.println("喵！");}公共无效batheSelf(){System.out.println("猫洗澡");}}我的问题是，我无法访问batheSelf() 方法，因为它只存在于Cat 中.这让我相信，如果我只打算使用在接口中声明的方法(而不是来自子类的额外方法)，我应该只从接口声明，否则我应该直接从类声明(在这种情况下为 Cat).我的这个假设是否正确?
当需要选择通过 interface 或 class 引用对象时，前者应该是首选，但仅当存在适当的类型时.
考虑 String实现CharSequence 为例.在所有情况下，您不应该盲目地使用 CharSequence 而优先于 String，因为那样会否定您的简单操作，例如 trim()、toUpperCase() 等
然而，一个接受 String 只关心它的 char 值序列的方法应该使用 CharSequence 相反，因为在这种情况下这是适当的类型.这实际上是 replace(CharSequence target, CharSequence replacement) String 类.
另一个例子是java.util.regex.Pattern 及其Matcher matcher(CharSequence) 方法.这让 Matcher 可以从 Pattern 创建，不仅用于 String，还用于所有其他 CharSequence
库中应该使用interface 的一个很好的例子，但不幸的是没有，也可以在Matcher:它的 appendReplacement 和 appendTail 方法只接受 StringBuffer.此类已在很大程度上被其更快的表亲取代 StringBuilder 从 1.5 开始.
A StringBuilder 不是 StringBuffer，所以我们不能将前者与 Matcher 中的 append… 方法一起使用代码>.但是，它们都实现Appendable(也在 1.5 中引入).理想情况下，Matcher 的 append... 方法应该接受任何 Appendable，然后我们就可以使用 StringBuilder，以及所有其他可用的 Appendable！
因此我们可以看到当存在适当的类型时如何通过接口引用对象可以是一个强大的抽象，但前提是这些类型存在.如果该类型不存在，那么您可以考虑定义自己的类型(如果有意义).例如，在这个 Cat 示例中，您可以定义 interface SelfBathable.然后，您可以接受任何 SelfBathable 对象(例如 Parakeet)
Cat如果创建一个新类型没有意义，那么你可以通过它的class来引用它.
另见
- Effective Java 2nd Edition，Item 52:通过接口引用对象<块引用>
如果存在合适的接口类型，则参数、返回值和字段都应使用接口类型声明.如果你养成使用接口类型的习惯，你的程序就会灵活得多.如果没有合适的接口存在，用类来引用一个对象是完全合适的.
相关链接
In my quest to correctly grasp Interface best practices, I have noticed declarations such as:
List<String> myList = new ArrayList<String>();
instead of
ArrayList<String> myList = new ArrayList<String>();
-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");
}
}
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.
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.
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.
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.
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 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!
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)
If it does not make sense to create a new type, then by all means you can refer to it by its class.
See also
- 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.
Related links
这篇关于Java - 从接口类型而不是类声明的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
