在C ++中（至少十年前），在头文件中定义类方法的主体时有速度优势，其中定义了类。没有函数调用开销，因为在编译过程中，这些函数的调用被函数体中的代码所取代。随后，可以使用所有源级别优化（以及源级别以外的所有优化）。
将类方法的主体放在classdef文件本身而不是单独的m文件中是否有类似的优势？我特意讲了一个定义@ myclass / myclass.m的情况，在@myclass目录中使用方法m文件。我考虑的两个选项是将mymethod方法体的代码放入@ myclass / myclass.m中的classdef而不是单独的文件@ myclass / mymethod.m。
然而，一个非常相关的辅助问题是这两个选项如何与myclass.m文件中定义的所有内容相比，没有文件夹@myclass。
请注意，我之前已将此内容发布到usenet
答案 0 :(得分：0)
总结注释作为这个问题的答案：使用包含单独方法m文件的@classFolder文件夹比使用包含classdef中函数定义的全部的单个m文件更快。即使OOP总体上在2015b加速了，也是如此。
我觉得这是一个很好的答案，因为我认为将类的方法的代码实现与类定义本身分开是很有价值的。这就是将接口与实现分离的整个想法。我可以查看classdef并只查看该类的映射，而不是将这些关键信息元素完全分散在实现所伴随的大量代码中。
这对于弱类型语言来说效果不是很好。 classdef中列出的内容只是成员名称（属性或方法），没有规定它们是什么类。所以没有像强类型语言那样多的信息。事实上，关于类，它的属性和方法究竟是什么的信息非常少。此外，没有什么可以确保实际的方法实现甚至符合classdef中的参数列表。这些细节有助于防止强类型语言中的开发错误，特别是当一个类的体积变大时。