经典OOP优于Go语言

我一直在思考语言设计以及“理想”编程语言所必需的要素，而对Google Go的研究使我提出了很多其他常识。

具体来说，Go似乎从面向对象的编程中获得了所有有趣的好处，而实际上没有任何面向对象语言的结构。没有类，只有结构。没有类/结构继承-仅结构嵌入。没有任何层次结构，没有父类，没有显式的接口实现。取而代之的是，类型转换规则基于类似于鸭子类型的松散系统，因此，如果结构实现“阅读器”，“请求”或“编码”的必要元素，则可以对其进行转换并使用它作为一个。

用C ++和Java和C＃实现的OOP是否具有某种固有的功能，更可维护，更强大的功能，而在转向Go这样的语言时，您必须放弃这些功能？为了获得这种新范例所代表的简单性，您必须放弃什么好处？

编辑
消除了读者似乎过分迷恋和激怒的“过时”问题。

问题是，在普通语言实现中经常看到的传统的面向对象范式（具有层次结构等）必须提供哪些在这种简单模型中无法轻松实现的范式？或者，换句话说，如果您今天要设计一种语言，是否有理由要包含类层次结构的概念？

没有新的范例。面向对象是用于编写程序的一种模式，甚至没有明确定义。各种语言提供了面向对象的各种典型特征（定义新类型，封装，类型层次结构，多态性，消息传递等等），但可能无法提供其他特征。在这种情况下，如果需要，则由程序员来模仿它们。

提供这些功能的许多语言都没有类概念的类似物，例如Javascript和Common Lisp。类似Java的语言（基于类，具有单个继承，接口，基于类型的分派）提供的实现只是可能性之一，而不一定是最好的可能性。

为了获得这种新范例所代表的简单性，您必须放弃什么好处？

与简单地检查基类是否在继承列表中相比，结构类型系统的类型检查要复杂得多。虚拟调度变得有些棘手，并且性能可能会降低。

这样的系统会淘汰OOP的概念吗？

不需要。只要您可以根据“做事的对象”而不是指令列表，已声明的规则集或一系列级联的函数来编写程序，则实现无关紧要。同样，更改类型系统不会使任何通用的OO原则无效。

您仍然可以使用基本类型，而不必关心其实际类型。您仍然可以扩展类型而不修改它们。您仍然可以使类型仅做一件事。您仍然可以提供细粒度的接口。您仍然可以为类型提供抽象。

语言如何允许这并不重要。

我认为您对OOP的想法有些偏离：

我发明了术语“面向对象的程序设计”，而这个{Java and C ++}并不是我想要的。
- 艾伦·凯（Alan Kay）。

类型的选择（标称子类型，结构子类型或鸭子类型-或它们的组合）在很大程度上与OOP正交。继承和类与OOP完全正交。如果您花一些时间玩io，那么您会发现它。

现在，您可以询问哪种类型的系统“更好”，以及哪种代码重用和组合方式。并尝试确定在Simula中进行选择（后来在C ++，Java和C＃中进行）与Go中进行选择之间的优缺点。但是，这些都是不同且截然不同的问题。

最终，OOP是一个非常模糊的概念，实现它的所有尝试都有各种各样的口味。但是要真正简化事情，我想说OOP的核心思想是组成SOLID子系统的系统。现在，这无疑使与其他范式的界限模糊了，但是我推测这就是为什么多范式语言最近变得越来越流行以及Google用Go自己解决这一问题的原因。

OOP并不是过时的。

正如Andrea所说，已经提出了许多替代类的概念（例如：haskell类型类）。OOP有一个很大的好处：它在很多地方都可以接受，并且OOP的文化在开发人员之间广泛共享。

这使得团队内部的交流更加丰富。与Zygohistomorphic的预原型相比，谈论工厂更为容易。OOP构建了您将使用常用图表组织和交流程序的方式。这是一项强大的资产。

不，这里没有新内容，OOP也不会过时。C ++也以模板的形式具有隐式接口，但是人们仍然使用虚函数。您需要显式接口来应对，例如二进制接口或在编译时根本不知道其他代码的接口。

您可能会争辩说，这只是推理而不是明确说明的情况，这与“新范式”无异，实际上更加方便。