language-agnostic - 强制转换的能力不会破坏类型变量的目的吗？

Question

所以，我假设我们已经输入了语言，因为我们犯了很多错误......所以输入是让编译器为我们做很多检查并帮助我们的一种方式（请让我知道是不是我的假设不正确）。

但是，如果我们将强制转换引入类型化语言，难道我们不会重新引入我们在无法类型化变量时遇到的大多数问题吗？

我也知道我的假设并不是我们键入变量的唯一原因。请分享我们输入语言的其他一些原因。

score 13 · Accepted Answer

13

底线是强类型让编译器为你检查，强制类型转换让你在必要时覆盖强类型。

于 2008-10-07T22:43:17.887 回答

score 3 · Accepted Answer

我会说“基本上不”。

如果您必须进行显式转换，您仍然可以避免动态类型引入的大多数问题。您的方法仍然需要存在于新类中。对象之间仍然必须具有某种层次关系。

能够将 XmlTextReader 转换为 TextReader 与能够在运行时确定 reader 具有称为“read”的成员并且可能是布尔值或可能是方法之间存在天壤之别。

score 2 · Accepted Answer

所以打字是让编译器为我们做很多检查并帮助我们的一种方法

是的。

但是，如果我们将强制转换引入类型化语言，难道我们不会重新引入我们在无法类型化变量时遇到的大多数问题吗？

是的。

你应该尽可能避免它，但有时你仍然需要做肮脏的工作。

当然，有很多语言不强制执行严格的键入，并且很多人喜欢它们并使用它们完成有用的工作。

score 1 · Accepted Answer

是的，强类型允许编译器为你做很多检查。

不，允许强制转换并不会停止它的有用性。关键是在极少数情况下需要进行强制转换时，它是明确的。程序员必须做出决定来制作演员表并且可以小心。铸造是一个有用的工具，就像许多强大的工具一样，它应该小心使用。

score 1 · Accepted Answer

至少在Java中，不是真的。您只能投射到您期望的班级的孩子。因此，如果您的类返回 RuntimeException，则不能将其强制转换为字符串，也无需将其强制转换为异常（它是父级）来访问它。

您只需将其转换为说您知道这实际上是 RuntimeException 的子/实现，并且您需要访问孩子知道的关于 RuntimeException 不知道的东西。

也就是说，过多的选角是不好的 OO 气味。您应该几乎完全通过父母公开的方法来访问孩子的唯一代码——如果您发现自己铸造了很多，也许您忘记了这条规则。

score 0 · Accepted Answer

当您进行强制转换时，您明确要求编译器放松其强类型。这允许您在 99% 的情况下进行编译时检查，但仍然在绝对必要时混合类型。

无论如何，编译器有可能在编译时发现“坏”的强制转换——那些没有成功的机会。

所以说启用强制转换否定了强类型的好处是错误的。然而，这可以说是过度使用铸造。

score 0 · Accepted Answer

打字还允许 Visual Studios Intellisense 等工具工作，这对提高生产力有很大帮助。

但除此之外，迈克 B 是对的。有时你只需要做一些肮脏的事情，比如将接口转换为类，或者将 longs 转换为 int。

score 0 · Accepted Answer

但是，如果我们将强制转换引入类型化语言，难道我们不会重新引入我们在无法类型化变量时遇到的大多数问题吗？

我没有看到指定的语言，但应该指出的是，在铸造方面有不同的程度。

例如，C++ 有一个 dynamic_cast，如果一个对象不能通过其继承关系转换为另一个对象，它将返回 NULL。

const_cast 将抛弃对象的常量性。这对于将 const 对象传递给未声明为 const 但您知道不会更改对象的方法可能很有用。

8 回答 8