objective-c - 什么时候定义Objective-C方法？

Question

我正在学习Objective-C，并且具有C / C++背景。

在面向对象的C++中，即使在父类中声明了方法，也始终需要在定义(实现)该方法之前先声明它。

在程序样式C(IIRC)中，只要定义一个函数，只要它是从同一文件中后来出现在同一编译单元(即同一文件)中的其他地方调用的，就可以摆脱它。前提是您未在其他地方用“extern”声明它)。

现在，在Objective-C中，似乎只需要在头文件中声明选择器(如果它们将被外部对象使用)，就可以在.m文件中组成选择器，并对其进行调用。在.m文件中。同样，似乎从未(重新)定义委托(delegate)方法或继承的方法。

我在正确的轨道上吗？什么时候需要在Objective-C中定义选择器？

Answer 1

对于Objective-C方法，通常的做法是将希望公开的方法放在头文件的@interface部分中，以便其他代码只能包含.h并知道如何与您的代码进行交互。基于订单的“惰性声明”就像C中的函数一样工作—您不必来声明方法原型(prototype)，除非您具有无法通过排序解决的依赖关系，但是可以在@implementation内添加方法原型(prototype)需要。

是的，您的方向正确。不要为继承的方法重复方法原型(prototype)—编译器会在父级的头文件中找到它。可以将委托(delegate)方法定义为类别中的原型(prototype)(添加到类中)，并根据需要实现，但是委托(delegate)不需要提供方法原型(prototype)，因为它已经定义。 (如果想澄清等，它仍然可以。)

由于您只是在学习Objective-C，因此此答案的其余部分比您要求的要详细得多。你被警告了。 ;-)

当您静态键入变量(例如MyClass*而不是id)时，当您尝试调用某个方法时，无论该类是否实现，该编译器都会警告您。如果您动态键入变量，则编译器不会阻止您调用任何您喜欢的内容，并且仅当您调用不存在的内容时才会出现运行时错误。就语言而言，您可以在运行时调用类实现的任何方法而不会出现错误-无法限制谁可以调用方法。

我个人认为这实际上是一件好事。我们已经习惯于封装和保护我们的代码，使其免受其他代码的侵害，以至于有时我们将调用者视为vious回的不道德行为，而不是可信赖的同事或客户。我发现以“您尽力而为，我尽我所能”的思维方式进行编码是一件非常令人愉快的事情，每个人都尊重边界并照顾好自己的事情。您可能会说，Objective-C的“态度”是社区信任的一种，而不是严格的执行。例如，我很乐意为来到我办公桌前的任何人提供帮助，但是如果有人不经意就弄乱了我的东西或四处走动，我会很生气。精心设计的代码不一定要偏执狂或社交性强，而必须协同工作。 :-)

就是说，有许多方法来构造您的界面，具体取决于您希望/需要向用户公开界面的粒度级别。您在公共(public) header 中声明的任何方法本质上都是公平的游戏，任何人都可以使用。隐藏方法声明有点像锁定您的汽车或房屋-可能不会使所有人都离开，但(1)通过不诱使他们不要让他们弄乱的东西来“使诚实的人诚实”，以及(2 )确实参加的任何人肯定会知道自己不应该这样做，也不能真正抱怨负面后果。

下面是一些我用于文件命名的约定，以及每个文件中的内容-从底部的.m文件开始，每个文件都包括上方的文件。 (使用严格的include链将防止出现重复的符号警告之类的问题。)其中一些级别仅适用于较大的可重用组件，例如Cocoa框架。根据您的需要调整它们，并使用适合您的名称。

MyClass.h —公共(public)API(应用程序编程接口(interface))

MyClass_Private.h —公司内部的SPI(系统编程接口(interface))

MyClass_Internal.h —项目内部IPI(内部编程接口(interface))

MyClass.m —通常实现所有API / SPI / IPI声明

MyClass_Foo.m —附加实现，例如

类

API供所有人使用，并且受到公共(public)支持(通常在 Foo.framework/Headers中)。 SPI为您的代码的内部客户端提供了其他功能，但应了解支持可能会受到限制并且接口(interface)可能会发生变化(通常在 Foo.framework/PrivateHeaders中)。 IPI包含特定于实现的详细信息，这些详细信息切勿在项目本身之外使用，并且这些 header 完全不包含在框架中。选择使用SPI和IPI调用的任何人均需自担风险，并且通常在更改破坏其代码时对其有害。 :-)