design-patterns - 对象转换是一个好习惯吗？

Question

面向对象的编程语言，例如java, c#, ... 支持对象类型转换。例如，这在 java 中是完全有效的:

URL url = new URL("url");    
URLConnection conn = url.openConnection();

if( !conn instanceof HttpURLConnection )
  throw new Exception("not http request");

HttpURLConnection con = (HttpURLConnection) conn;   

或者我尝试过的另一个基本示例:

public class Base
{
  public void base(){}
}

public class Derived extends Base
{
  public void derived(){}
}

Base b = new Derived();
b.base();

派生类拥有基类拥有的所有方法，以及更多。没有理由不能通过调用派生类构造函数来创建基类。

我也遇到了这个链接 http://www.volantec.biz/castingObjects.htm它解释了对象类型转换如何在内部工作。到目前为止，好的。

但是为什么第一个例子不使用 HttpURLConnection con = new HttpURLConnection("url address") (我知道 HttpURLConnection 是一个抽象类)。它只是看起来更清晰，更简单。另一方面，当您处理 interfaces, object typecasting comes in handy .另一个例子是 List<Object>列表，我有时会在某些类(class)中看到。这意味着您可以在此列表中保存所有可能的类(class)。之后，如果您知道它是什么类型，则可以将其转换为原始类型。仅将特定类保存到列表中会不会更清楚，即 List<String> , List<MyClass> .正在使用 List<Object>那么好的设计实践呢？

Answer 1

在设计类层次结构时，您必须始终保留 Liskov's Substitution Principle (aka, LSP)心里:

Derived types must be completely substitutable for their base types.

换句话说，要决定是否应该扩展一个类，你应该问自己，如果你将它更改为它的基类，依赖于你的新类的组件是否会得到很好的服务。

强制转换的问题在于，如果您需要将基类对象转换为派生类对象，则意味着您违反了 LSP。

如果您在期望接口(interface)时需要确保对象来自特定实现，那么您的设计肯定有问题。

接口(interface)就像合约。如果您正在使用不在接口(interface)中的实现方法，则意味着您正在破坏该契约(Contract)，从而在代码和实现之间创建耦合。

请记住，您的代码应始终为 rely on abstractions rather than concretions .