非OOP编程中的多态性的替代方案？

Question

假设我们有一个具有不同元素的绘图程序，例如圆形，矩形，三角形等等。不同类型的对象都需要类似的功能，例如draw()来显示自己。

我想知道程序员如何处理现在通常由多态性解决的问题，即通过不同元素的集合并调用不同对象的通用功能。

想到的一种方法是使用一个函数指针指向相应函数（或函数指针数组中的索引）的结构以及指向实际实例的void指针，并传递该指针到函数中正确的类型。但那只是我 - 一个对这个问题毫不知情的人会这样做的。

我的确意识到这可能是一个不好的问题，但由于我在“古代”时代还没有出现过，我真的不知道这个问题是如何解决的。程序编程中使用了什么样的方法，并且它具有性能优势，因为我们都知道，由于虚拟方法查找，多态性即使在像C++这样的快速语言中也有开销。

Answer 1

在程序语言，如C，这将通过定义每个自定义数据类型（大概表示为结构）的draw()功能的单独实施加以解决。任何常见的功能都会被分解成一个单独的函数，该函数在每个结构的共享元素上进行操作（例如对象中心的x坐标和y坐标，它们将出现在每个结构中）。从代码和功能的角度来看，这与使用多态的OOP布局没有多大区别，您仍然必须在基类中实现共享的draw()方法，并在特定的子类中重写它。在程序语言的情况下，我们不会将这些函数定义分解成单独的“对象”。

有一些奇特的方法可以从程序语言中获得类似对象的行为，例如联合类型或带有额外布尔值的单一整体类型，以确定是否正在使用特定元素。这将允许您编写一个单一的draw()函数，该函数可以根据启用了哪些元素来执行逻辑切换。在实践中，我唯一见过的地方是基于CORBA的系统，其中用C语言编写的程序必须模仿通过IDL传播的OOP语言的一些行为（即将Java对象翻译成构造可以解码为C风格的结构）。

至于诸如C++和Java之类的语言中虚拟方法查找的开销，这在面向对象的语言中是无法完全避免的。通过正确使用final关键字（它允许编译器/ JVM优化方法查找表）可以很好地缓解这个问题。

Answer 2

这不是直接回答你的例子，但一个地址给你的评论，这显示了一个错误的观点恕我直言

我只是想知道有关具体问题，如果有最感兴趣 更高效办法避免的虚方法

也有一些是了解这里的性能开销 。 一切有一个折衷。设计模式和OO具有我们所喜爱的所有已知优点，但也具有缺点，例如太多类，内存开销，由于许多方法调用等导致的性能开销。

在另一方面旧的“程序”的方式有一些优势也成为目标;编码是“简单的”（不需要考虑如何设计系统，只需将所有内容都放在主体中），并且在很多方面开销较少（因为需要更少的类和更紧凑的对象，所以内存开销更少） - 不需要虚拟表等等 - 而且更少的方法调用，所以也许更好的性能，动态绑定没有性能开销 - 不管现在的开销如何 - ）。

但它不是什么特定问题实例的权衡取舍，它是什么经验表明什么是构建软件的正确方法。 重用的代码，模块化和在独立的测试（质量保证），可读，维护协助，柔性的，以延伸是已被很好地理解的属性应该是这样的主驱动器在软件开发中。

所以在某些情况下，C/C++中的程序员可以像你说的那样做“老路”，但是对于这个特殊的程序来说性能上的好处值得这样一个事实：没有人之后能够维持或维持？

再举一个类似的例子：你可以问以同样的方式？
为什么在web开发中使用多层体系结构？只要把一切都变成一台服务器，这将是快了很多，因为不会有任何的延迟在查询后端和用户界面的数据或远程数据库的查询等
网络延迟所有层 当然，你有一个观点。但是，然后问你的自我，这可以作为负荷增加？答案是不。因此，扩展性对您而言很重要，或者您希望保持“将所有内容放在一台服务器上”的想法？如果你的收入来自电子商务网站，但事实上，你不能为更多的客户不会让你的客户感到高兴，因为你担任第100真快......反正这是我的意见