Oop 面向对象原则应该应用于过程语言吗？

我知道，从原则上讲，甚至可以将C或MATLAB之类的过程语言转变为面向对象的语言。这个问题已经得到了相当充分的讨论和讨论

我发现在这些讨论和其中的参考文献中缺少的是关于是否应该应用这些原则的阐述。这样做有什么具体的好处吗？这显然是可能的，但这样做明智吗？在开源项目中，有没有这样的实践带来明显优势的例子

澄清

也许可以举个例子

我继承了一些实现一些机器学习算法的MATLAB代码。基本上只有一个函数

building_model

，根据传递的标志，该函数将训练模型或使用模型预测未来值：

building_model('train', ...) % ... stands for the data with which the model is trained

及

模型本身是在

building_model

中使用MATLAB持久变量实现的

我已经将

building_model

分解为两个函数，一个用于训练，一个用于预测。过去作为持久变量实现的模型现在外部化了，可以这么说：

model = new_model()
model = model_train(model, ...)
prediction = model_predict(model)

粗略地说，这是我在MATLAB中模拟OOP的一些特性所能做到的。我的建筑模型模块现在的行为很像一个类，有一个构造函数和两个方法

model\u train

和

model\u predict

。我已经实现了某种程度的封装（尽管没有什么可以阻止调用方摆弄

模型

的内部），原则上也可以适应多态性。作为额外的奖励，我几乎免费获得命令/查询分离，因为

model\u predict

不会返回

model

，因此可能不会改变

model

（精明的读者会指出，MATLAB已经有了一个面向对象的系统。出于各种原因，包括性能和与旧版本的兼容性，我不能使用它。）

我可以想象在C语言中有一种类似的机制，您可以设计一些数据结构并编写函数，这些函数的第一个参数是该数据结构的实例

我想知道的是，这种编程方式能推进多远？这是一种普遍接受的模式吗（我已经说过了）？是否有任何性能问题需要注意？

面向对象是实现软件工程目标的一种手段

目标：易于维护、可扩展性、有组织的源代码（可搜索性等）
OO构造：封装（只有“数据类型/结构”拥有的方法才能对其数据进行操作）

目标：能够在不修改现有功能的情况下开发新功能，代码重用
OO构造：实现继承、多态

目标：抽象（您不必承诺特定类型或操作，在不更改客户端的情况下更改实现）
OO构造：接口继承、接口、抽象类

这些目标不需要理由。您是否想要/需要OO语言的支持取决于您的具体情况。如果你需要使用C，你仍然可以模仿一些OO结构，并希望享受它的好处

请注意，在遵守所有OO原则的情况下，完全有可能开发出一大堆乱七八糟的代码

---

我相信其他人可以列出其他目标和示例（并且知道如何在stackoverflow帖子中编辑表格）

我认为这是一个非常重要的讨论。我认为可以肯定地说，OOP并不总是所有语言中最好的解决方案。例如，在C++或Python中，OOP通常是封装数据的自然方式。这些语言的设计重点是类。在其他语言中，以其他方式创建高质量代码可能更容易

我认为CommonLisp就是一个很好的例子。它有一个非常好的OOP系统（CLOS），我想说它是非常完整的。但是，OOP在Python或C++中的使用不尽相同，因为它是一个方便的特性，而不是提供基本软件工程构建块所需的东西。

---

您是否应该使用OOP实际上取决于您试图解决的问题。举个例子，我认为GUI的东西对于处理OOP是非常有用的。

这是关于面向对象实践的讨论中经常缺少的东西。您仍然需要确定OOP是否是正确的设计，无论它是内置在语言中还是仅仅是一种在没有语言帮助的情况下尝试采用的设计方法。无论哪种方式都有相同的优点（和缺点）。我真的不同意OO是实现上述目标的手段。在OO发明之前，这一切都是可能的。+1“我认为GUI的东西对OOP的处理非常有用。”。这就是Stroustrup博士向他的学生介绍OOP的方式。

model = new_model()
model = model_train(model, ...)
prediction = model_predict(model)