我什么时候定义objective-c方法? [英] When do I define objective-c methods?

问题描述

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

I'm learning Objective-C, and have a C/C++ background.

• 在面向对象的 C++ 中，您总是需要在定义(实现)方法之前声明它，即使它是在父类中声明的.

• In object-oriented C++, you always need to declare your method before you define (implement) it, even if it is declared in the parent class.

在程序风格的 C、IIRC 中，你可以只定义一个函数，只要它只是从稍后出现的同一编译单元(即同一文件)中的其他东西调用文件(好吧，前提是你没有在别处用extern"声明它).

In procedural-style C, IIRC, you can get away with just defining a function so long as it is only called from something else in the same compilational unit (ie. the same file) that came later on in the file (well, provided you don't declare it elsewhere with "extern").

现在，在 Objective-C 中，如果选择器将被外部使用，您似乎只需要在头文件中声明选择器，并且您可以在 .m 文件中组成选择器很好，并在 .m 文件中调用它们.此外，似乎从未(重新)定义委托方法或继承方法.

Now, in Objective-C, it appears that you only need to declare selectors in the header file if they are going to be used by something external, and that you can make up selectors in your .m file just fine, and call them within the .m file. Also, it appears that delegate methods or inherited methods are never (re)defined.

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

Am I on the right track? When do you need to define a selector in Objective-C?

推荐答案

对于 Objective-C 方法，一般的做法是将你希望公开的方法放在头文件的 @interface 部分所以其他代码只能包含 .h 并知道如何与您的代码进行交互.基于顺序的延迟声明"就像 C 中的函数一样——您不必必须声明方法原型，除非您有无法通过排序解决的依赖项，但您可以添加方法如果需要，@implementation 中的原型.

For Objective-C methods, the general practice is to put methods you wish to expose in the @interface section of the header file so other code can include only the .h and know how to interact with your code. Order-based "lazy declaration" works just like functions in C — you don't have to declare a method prototype unless you have a dependency that can't be resolved by ordering, but you can add method prototypes inside the @implementation if needed.

所以是的，你走在正确的轨道上.不要为继承的方法重复方法原型——编译器会在父级的头文件中找到它.委托方法可以定义为类别中的原型(附加到类中)并根据需要实现，但委托不需要提供方法原型，因为它已经定义了.(如果它想清楚等，它仍然可以)

So yes, you're on the right track. Don't repeat the method prototype for inherited methods — the compiler finds it in the parent's header file. Delegate methods may be defined as prototypes in a category (tacked onto a class) and implemented as desired, but the delegate does not need to provide a method prototype, since it is already defined. (It still can if it wants to for clarity, etc.)

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

当您静态键入变量(例如 MyClass* 而不是 id)时，编译器会在您尝试调用类未公开的方法时警告您它实施，无论是否实施.如果您动态键入变量，编译器不会阻止您调用您喜欢的任何内容，并且只有在您调用不存在的内容时才会出现运行时错误.就语言而言，您可以在运行时调用类实现的任何方法而不会出错——没有办法限制谁可以调用方法.

When you statically type a variable (e.g. MyClass* instead of id) the compiler will warn you when you try to call a method that a class doesn't advertise that it implements, whether it does or not. If you dynamically type the variable, the compiler won't stop you from calling whatever you like, and you'll only get runtime errors if you call something that doesn't exist. As far as the language is concerned, you can call any method that a class implements without errors at runtime — there is no way to restrict who can call a method.

就我个人而言，我认为这实际上是一件好事.我们习惯于封装和保护我们的代码免受其他代码的影响，有时我们将调用者视为狡猾的恶棍，而不是值得信赖的同事或客户.我发现以你做你的工作，我做我的"的心态编码是很愉快的，每个人都尊重界限并照顾好自己的事情.你可能会说，Objective-C 的态度"是一种社区信任，而不是严格执行.例如，我很乐意帮助任何来到我办公桌前的人，但如果有人在没有询问的情况下弄乱了我的东西或移动了东西，我会非常生气.精心设计的代码不必偏执或反社会，它只需要很好地协同工作.:-)

Personally, I think this is actually a good thing. We get so used to encapsulation and protecting our code from other code that we sometimes treat the caller as a devious miscreant rather than a trustworthy coworker or customer. I find it's quite pleasant to code with a mindset of "you do your job and I do mine" where everyone respects boundaries and takes care of their own thing. You might say that the "attitude" of Objective-C is one of community trust, rather than of strict enforcement. For example, I'm happy to help anyone who comes to my desk, but would get really annoyed if someone messed with my stuff or moved things around without asking. Well-designed code doesn't have to be paranoid or sociopathic, it just has to work well together. :-)

也就是说，有很多方法可以构建您的界面，具体取决于您希望/需要向用户公开界面的粒度级别.您在公共标头中声明的任何方法本质上都是公平的，供任何人使用.隐藏方法声明有点像锁住你的车或房子——它可能不会让每个人都被拒之门外，但是 (1) 它让诚实的人保持诚实"，不会用他们不应该弄乱的东西来诱惑他们，和 (2) 任何确实进入的人肯定知道他们不应该进入，并且不能真正抱怨负面后果.

That said, there are many approaches for structuring your interfaces, depending on the level of granularity you want/need in exposing interfaces to users. Any methods you declare in the public header are essentially fair game for anyone to use. Hiding method declarations is a bit like locking your car or house — it probably won't keep everyone out, but (1) it "keeps honest people honest" by not tempting them with something they shouldn't be messing with, and (2) anyone who does get in will certainly know they weren't supposed to, and can't really complain of negative consequences.

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

Below are some conventions I use for file naming, and what goes in each file — starting from a .m file at the bottom, each file includes the one above it. (Using a strict chain of includes will prevent things like duplicate symbol warnings.) Some of these levels only apply to larger reusable components, such as Cocoa frameworks. Adapt them according to your needs, and use whatever names suit you.

• MyClass.h — 公共 API(应用程序编程接口)
• MyClass_Private.h — 公司内部 SPI(系统编程接口)
• MyClass_Internal.h — 项目内部 IPI(内部编程接口)
• MyClass.m — 实现，通常是所有 API/SPI/IPI 声明
• MyClass_Foo.m — 其他实现，例如类别

• MyClass.h — Public API (Application Programming Interface)
• MyClass_Private.h — Company-internal SPI (System Programming Interface)
• MyClass_Internal.h — Project-internal IPI (Internal Programming Interface)
• MyClass.m — Implementation, generally of all API/SPI/IPI declarations
• MyClass_Foo.m — Additional implementation, such as for categories

API 供所有人使用，并受到公开支持(通常在 Foo.framework/Headers 中).SPI 为您的代码的内部客户端公开了附加功能，但理解支持可能是有限的，并且接口可能会发生变化(通常在 Foo.framework/PrivateHeaders 中).IPI 由不应在项目本身之外使用的特定于实现的细节组成，并且这些头文件根本不包含在框架中.任何选择使用 SPI 和 IPI 调用的人都需要自担风险，并且通常在更改破坏他们的代码时对他们不利.:-)

API is for everyone to use, and is publicly supported (usually in Foo.framework/Headers). SPI exposes additional functionality for internal clients of your code, but with the understanding that support may be limited and the interface is subject to change (usually in Foo.framework/PrivateHeaders). IPI consists of implementation-specific details that should never be used outside the project itself, and these headers are not included in the framework at all. Anyone who chooses to use SPI and IPI calls does so at their own risk, and usually to their detriment when changes break their code. :-)

这篇关于我什么时候定义objective-c方法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！