Item 更喜欢接口而不是反射

文章小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《Item 更喜欢接口而不是反射》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

java 中的反射 (java.lang.reflect):
通过反思，有可能：

• 以编程方式访问任意类的构造函数、方法和字段。
• 以反射方式操作类及其成员（构造函数、方法、字段），允许您创建实例、调用方法和访问字段。
• 即使类在编译期间不存在，也可以调用对象的方法。

反射的缺点：
编译时类型检查丢失：

• 通常在编译时检测到的错误只会在运行时出现。
• 示例：反射性调用不存在或不可访问的方法可能会在运行时生成异常。

繁琐的代码：
反射需要更复杂且可读性较差的代码。
示例：

method method = obj.getclass().getmethod("methodname");
method.invoke(obj, args);

表现不佳：

• 反射方法调用比普通调用慢得多。
• 示例：在某些场景下，反射可能比直接方法调用慢 11 倍。

反射的应用：

• 用于代码分析工具、依赖注入框架和服务提供框架。
• 即使在这些情况下，由于其缺点，也应尽可能避免。

有限使用反射：
建议技术：仅使用反射在编译时实例化未知类，并通过已知接口或超类引用这些实例。

示例：
创建 set 实例的程序，由命令行指定：

Class> cl = (Class>) Class.forName(args[0]);
Constructor> cons = cl.getDeclaredConstructor();
Set s = cons.newInstance();
for (int i = 1; i < args.length; i++) {
    s.add(args[i]);
}
System.out.println(s);

示例中说明的缺点：
运行时异常：

• 该示例在运行时最多可以生成六个不同的异常。
• 如果不使用反射，这些异常将在编译时被捕获。

复杂性和冗长：

• 该示例需要 25 行代码才能从名称实例化一个类，而直接调用构造函数只需一行代码即可完成。

未经验证的演员警告：

• 在示例中，存在未检查强制转换的合法警告，因为命令行上指定的类可能不是 set 的实现。

反射的合法使用：

• 动态依赖：当类、方法或字段在运行时可能不存在时。
• 示例：您可以使用反射来支持包的多个版本，而不会破坏向后兼容性。

结论：
反射很强大，但它也有很多缺点。
只要有可能，仅使用反射来实例化对象并通过编译时已知的接口或超类访问它们。

书中的示例：

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。