关于面向对象中为什么要将函数与类进行绑定?

我学过一点C语言。C语言主要是用函数解决问题(学的时候也不知道这是面向过程)。总之觉得函数就可以解决一切问题,数据送进去,函数给出处理结果。问题解决。

然后这几天看了面向对象的内容(matlab)。看到构建类的时候,有一点不太明白。

先说说我对“类”的“认识”,然后再提出问题。如果“认识”部分哪里错了还请各位指正!

认识:类就像一个word中的“格式刷”。你定义好了一个类,就可以用类去制造对象。或者可以看成一个excel模板,你定义好了一个“学生类”的数据模板,包括:姓名、性别、身高、体重、年级、班级、各科成绩。然后你往这个模板中录入了张三李四的信息后。张三李四就被这个模板塑造成了“类”的“对象”。 C语言中的“结构体”也可以为建立结构化数据打下一个模板?(能不能像“类”一样批量制造对象我就不清楚了,没用过)

问题:函数处理数据要对数据类型进行规范,比如我编了一个函数,作数值加法。输入参数x,y。 函数内:z=x+y 输出参数是 z ,变量类型必须数值型。不能是逻辑变量,也不能是字符类型,也不能是数组类型。虽然函数只能处理特定类型的变量,但是没必要和变量进行强绑定吧? 那么为什么在定义“类”的时候,下面要给出一段代码让你写“方法” ?(我看来看去这个方法就是个处理类数据的特定函数。如果理解有误请指正)。我想知道定义类的时候同时定义对应的方法,目的是什么? 我猜不在类中定义方法。你在外面写个函数处理类定义的结构化数据应该也是可以的吧?但是类中留出定义方法的空间,一定是有好处的?这个好处是什么呢? 我看视频介绍把大象装进冰箱为例。大象这个类中定义了,打包大象这个方法。 冰箱这个对象中定义了,开门,塞进物品,关门这三个方法。 但是 打包,开门,塞进物品,关门 这几个函数我想不写在类中应该也不是不可以吧? 只要这些函数能兼容大象,冰箱这些特定的结构化数据应该一样可以工作吧?

那么在类中定义函数的_最主要_目的是什么呢? 增加代码可读性可维护性?可以封装隐藏函数,保护知识产权? 便于从现实到代码的抽象?提高程序运行效率? 其它?

----------------------如果是chatgpt的答案请注明。

做一个类比,面向过程比不面向过程的好处是什么?
如果没有面向过程,代码的是“散装的”,如同一盘散沙,你无法隔离或者提取某个功能的代码,全部在一起意味着无法维护和无法重用。
面向对象和面向过程是同理,面向过程的代码不是散装的了,但是数据和函数本身还是散装的,任何函数都可能会调用另一个函数,你把某个函数拿出来放在另一个项目里,你会发现它还依赖了别的东西。而面向对象进一步把函数和数据封装起来了。函数只能调用同一个类的其他函数,或者是别的类的公有函数,不能随便调用了。
再做一个类比,结构化编程(使用 for if switch)和非结构化(使用goto语句)有什么优势?前者基本上实现了控制流的单向封闭,不能随便从后面跳转到前面。而面向对象也是一样的,实现了函数依赖的单向性。

问题: 为什么在面向对象编程中需要将函数与类绑定?

在面向对象编程中,将函数与类绑定是为了实现类的行为和功能。类是一种将数据和操作封装在一起的抽象化表示,而函数则是用于处理数据的操作。将函数与类绑定可以实现以下目的:

  1. 封装性和抽象化: 类将数据和对数据的操作封装在一起,通过定义类的方法来实现对数据的处理。通过将函数与类绑定,可以将相关的操作组织在一起,方便代码的组织和管理。这样做可以提高代码的可读性和可维护性。同时,类的方法也可以对应类的实例进行特定的操作,使得代码更加具有逻辑性和结构性。

  2. 代码复用和继承: 类可以被其他类继承,从而继承父类的属性和方法。通过在类中定义的方法,可以实现对父类方法的重写,或者在基础上新增一些特定的功能。这样可以实现代码的复用,减少重复编写相似功能的代码。

  3. 数据安全和封装: 通过将函数和数据封装在类内部的方法中,可以对一些敏感数据和操作进行封装和隐藏,外部无法直接访问和修改。类的方法可以对数据类型进行规范,确保数据的正确性和安全性。

  4. 接口一致性和扩展性: 类的方法定义了对象的行为和接口,实现了一致性的接口规范。不同的类可以实现相同的方法,从而实现了多态性。这样在编程中,可以通过调用相同的方法名来实现不同的功能,提高代码的灵活性和扩展性。

综上所述,将函数与类绑定是为了实现代码的组织和管理,增加代码的可读性和可维护性,实现代码的复用和扩展性,并确保数据的安全性和规范性。

在Matlab中,类的方法的定义和实现是通过函数来完成的。在类中定义的方法可以对类的属性进行操作和处理,实现类的行为和功能。这样做可以将数据和操作封装在一起,提高代码的可读性和可维护性,同时也保证了数据的安全性和规范性。所以在面向对象编程中,将函数与类绑定是必要的。