使用C函数而不是静态方法使纯函数设计不好吗?

时间:2013-07-20 09:15:53

标签: objective-c

如果我正在实现一个基于某些输入进行某些计算的函数并返回输出而不会产生任何副作用。

我总是使用Regular C函数,而不是在类中使用静态方法。

使用强制放入类的静态方法背后有理由吗?

我不是在谈论创建单身人士或工厂方法的方法,而是像那里那样的常规方法:

而不是像这样:

+(NSString *)generateStringFromPrefixString:(NSString *)prefixString word:(NSString *)word;

这不会更好吗?

NSString *generateString(NSString *prefixString, NSString *word);

在效率方面,我们不会保存,查找选择器以获取函数指针吗?

4 个答案:

答案 0 :(得分:3)

Objective-C没有“静态方法”这样的东西。它有类方法。这不仅仅是挑选一个因为类方法是动态调度的,而不是静态调度。这可能是使用类方法而不是函数的一个原因:它允许子类覆盖它。

相比之下,这也可能是使用函数而不是类方法的原因 - 以防止它被覆盖。

但是,一般来说,没有必须使用类方法的规则。如果某个功能适合您的需求和偏好,请使用功能。

答案 1 :(得分:2)

我认为这不是糟糕的设计,不是,但在某些情况下,人们可能认为比另一种更合适。关键问题是:

  • 此方法是否属于某个类?
  • 这种方法值得加入一个类吗?

一个类是自包含和可重用的东西。对于你的例子中的方法,我很想回答“是的,它确实/是”,因为它是NSString特有的东西,并且是你(大概)想要经常使用的方法。其参数也是NSString类型。因此,我会在类扩展中使用消息表单,并在需要时使用#import扩展名。

有两种情况(在我的头顶),这是不合适的。首先是该方法与“主类”之外的其他实体具体交互的情况。可以在Apple的NSObjcRuntime.h文件底部附近找到此示例。这些都是标准的C函数。它们并不属于特定类别。

使用标准C函数的第二种情况是在非常特定的情况下它只会被使用一次(或非常几次)。 UIApplicationMain是一个很好的例子,也可以想到特定UIView子类的-drawRect:方法的辅助方法。

关于效率的最后一点。是的,选择器查找比较慢的标准C调用。但是,运行时(Apple至少不能对GCC发表评论)确实使用了缓存系统,因此最常发送的消息很快就会转移到选择器表的“顶部”。

免责声明:这在某种程度上是一种风格问题,上面的建议就是我这样做的方式,因为我认为它使代码更有条理和可读性。我确信还有其他同样有效的方法来构造/交错C和Objective-C代码。

答案 2 :(得分:2)

一个重要因素是可测试性。您的c函数是否特别需要测试? (在课程中,一切都必须经过理想的测试,但有时你可以通过调用它来调试它)。如果需要,您可以单独访问这些功能吗? 也许您需要模拟它们来测试其他功能?

截至2013年,如果您居住在Apple / Xcode / iOS / MacOS世界中,那么您更有可能拥有更多用于在objc中测试内容的内置工具而不是普通c。我想说的是: 模拟c函数更难

我非常喜欢C函数。起初我不喜欢他们在我漂亮的objc代码中。过了一会儿,我觉得这无关紧要。背景真的很重要。我的观点是(与NSObjcRuntime.h上的PLPiper相同)有时,通过判断其名称或功能,函数不属于任何类。所以没有语义上的理由让它们成为一个类方法。当我开始编写包含多个内联 c函数的代码的测试时,所有这些模棱两可的东西都消失了。现在,如果我需要一些c函数进行专门测试,模拟等等,我知道在objc中更容易实现。有更多/更容易的内置工具来测试c。

的对象

感兴趣的是:Function mocking (for testing) in C?

答案 3 :(得分:0)

为了保持一致性和程序员的期望,我想说使用Objective C风格。我不喜欢混合呼号和功能符号,但你的里程可能不同。