对于那些不熟悉这个概念的人来说,抽象反转是在高级构造之上实现低级构造,并且通常被认为是一件坏事,因为它增加了不必要的复杂性和不必要的开销。当然,这是一个有点不精确、主观的定义。
在您看来,使用单一范式 OOP 语言进行编程,其中所有内容都必须是类的一部分,并且不会暴露诸如指针之类的东西,例如 Java 或 C#,是否不可避免地会导致抽象反转?如果是,在什么情况下?
对于那些不熟悉这个概念的人来说,抽象反转是在高级构造之上实现低级构造,并且通常被认为是一件坏事,因为它增加了不必要的复杂性和不必要的开销。当然,这是一个有点不精确、主观的定义。
在您看来,使用单一范式 OOP 语言进行编程,其中所有内容都必须是类的一部分,并且不会暴露诸如指针之类的东西,例如 Java 或 C#,是否不可避免地会导致抽象反转?如果是,在什么情况下?
真正的程序员可以用任何语言编写 FORTRAN
换句话说,它不是语言,而是程序员
单一范式任何东西都违反了抽象的第一诫,似乎很少有人知道,甚至更少关心。
如有必要,您不得对您进行任何无法覆盖的抽象,以使您的代码没有丑陋的抽象反转。
不管你的范式是什么,一旦你开始编写重要的代码来解决现实世界的问题,你最终会得到一些不太适合范式的东西。如果你宣称只有一种范式,那就是事情变得丑陋的时候。
打个比方,当你只有一个木槌时,一切都开始看起来像一个木钉,如果你所有的洞都是圆形的,你突然变成了一些方形木钉,而你没有任何锯子,(只有木槌,) 你自己有问题。
There's no free lunch. Everything is a trade-off. The easier code becomes to write, the harder it becomes for someone else to read and maintain, or for you or anyone else to debug when problems occur below the level of abstraction that you're working at. (And they will eventually, because no abstraction is perfect.
This is the fundamental flaw with "helpful" technologies and paradigms such as managed code, garbage collection, JIT compilation and the "everything is an object" fiat. They impose a baseline level of abstraction that you are not allowed to reach beneath, and when something goes wrong below that level, there's nothing you can do about it. You're stuck working around a bad abstraction because you can't fix it.
Java 和 C# 具有等效于函数的静态方法,因此该语言不会强迫您做任何事情。
就是说,一旦我真正获得了 OO,我就没有任何想要转向另一种编程风格的愿望。
如果您的简单 OO 层覆盖了一些复杂的东西,我建议您的代码可能是个问题。如果 OO 做得对,它应该一直很简单。
我不认为像 Java 或 C# 这样的语言会以任何有形的方式受到这种影响,仅仅是因为框架附带的库非常丰富,以至于一般编程并不真正需要打破另一种范式。
也就是说,丰富的库本身可能会遭受抽象反转的影响,但是由于内部实现通常是隐藏的,或者关键类是密封的,试图扩展这些库的开发人员经常被迫重新实现/复制功能以成功利用扩展基类库提供的点 - 这与其说是语言问题,不如说是基类库的开发人员做出的有意识的选择,以避免暴露可能会随着 .Net Framework 的新版本而变得脆弱或经常更改的功能/JDK。
此外,由于 .Net Framework / Java Runtime 都允许与位于公共运行时之上的其他语言进行互操作,因此针对其他范式(例如函数式编程、动态语言等)的能力也可以提供另一种摆脱单一范式的途径约束。