所以，我的工作假设是我们已经输入了类型语言，因为我们犯了很多错误......所以打字是让编译器为我们做很多检查并帮助我们的一种方式（如果是我的假设不正确，请告诉我）。
但是，如果我们将强制转换引入类型化语言，难道我们不会重新引入我们在无法类型化变量时遇到的大部分问题吗？
我也知道我的假设并不是我们键入变量的唯一原因。请分享我们使用类型语言的其他一些原因。
【问题讨论】：
标签： language-agnostic programming-languages strong-typing
所以打字是一种获得 编译器为我们做了很多检查 帮帮我们吧
是的。
但是，如果我们将强制转换引入 类型语言，我们不要重新介绍 我们遇到的大多数问题不是 可以输入变量吗？
是的。
你应该尽量避免它，但有时你仍然需要做脏活。
当然，有很多语言不强制执行严格的键入，还有很多人喜欢它们并使用它们完成有用的工作。
【讨论】：
是的，强类型允许编译器为您进行大量检查。
不，允许投射并不会停止它的用处。关键是在极少数情况下需要进行强制转换时，它是明确的。程序员必须做出决定来制作演员表并且可以小心。铸造是一个有用的工具，就像许多强大的工具一样，它应该小心使用。
【讨论】：
底线是强类型让编译器为你检查事情，强制类型转换让你在必要时覆盖强类型。
【讨论】：
当您进行强制转换时，您明确要求编译器放松其强类型。这使您可以在 99% 的情况下进行编译时检查，但仍然在绝对必要时混合类型。
无论如何，编译器有可能在编译时发现“坏”的类型转换——那些没有成功的机会。
所以说启用强制类型转换否定了强类型的好处是错误的。然而，这可以说是过度使用强制转换。
【讨论】：
我会说“基本上不”。
如果您必须进行显式转换，您仍然可以避免动态类型引入的大部分问题。您的方法仍然需要存在于新类中。对象之间仍然必须具有某种层次关系。
能够将 XmlTextReader 强制转换为 TextReader 与能够在运行时确定 reader 具有称为“read”的成员并且可能是布尔值或方法之间存在天壤之别。
【讨论】：
打字还可以让 Visual Studios Intellisense 等工具工作，这对提高工作效率有很大帮助。
但除此之外，Mike B 是对的。有时你只需要做一些肮脏的事情，比如将接口转换为类，或者将 longs 转换为 int。
【讨论】：
至少在 Java 中，并非如此。您只能投射到您期望的班级的孩子。因此，如果您的类返回 RuntimeException，则不能将其强制转换为字符串，也无需将其强制转换为异常（它是父级）来访问它。
您只需将其转换为表示您知道这实际上是 RuntimeException 的子项/实现，并且您需要访问子项知道的有关 RuntimeException 不知道的内容。
也就是说，过多的选角是不好的 OO 气味。您应该几乎完全通过父母公开的方法来访问孩子的唯一代码——如果您发现自己投了很多，也许您忘记了这条规则。
【讨论】：
但是，如果我们将强制转换引入类型化语言，难道我们不会重新引入我们在无法类型化变量时遇到的大部分问题吗？
我没有看到指定的语言，但应该指出的是，在铸造方面存在不同的程度。
例如，C++ 有一个 dynamic_cast，如果一个对象不能通过其继承关系转换为另一个对象，它将返回 NULL。
一个 const_cast 将抛弃一个对象的常量。这对于将 const 对象传递给未声明为 const 但您知道不会更改对象的方法很有用。
【讨论】：