Objective-C：你在你的代码中使用@private 可见性/访问修饰符吗？

Posted 2023-02-23

【中文标题】Objective-C：你在你的代码中使用@private 可见性/访问修饰符吗？

【英文标题】：Objective-C: do you use @private visibility/access modifier in your code?

【发布时间】：2011-01-05 19:05:59

【问题描述】：

有 3 个修饰符：@private、@protected（默认）和@public。习惯于在 C++ 和其他更理智的语言中这样做，我总是在我的领域使用@private。我几乎没有（如果有的话）在 Apple 的 SDK 示例中看到这一点——它们只是依赖于默认的。

有一天，我意识到 Objective-C 继承是相当虚假的特性：从另一个接口派生接口并不意味着所有私有字段现在都可以重新定义。编译器仍然可以看到它们，并且不允许定义具有相同名称的新私有字段，这与 OOD 中的经典封装范式正交。

所以我有点沮丧。也许我对这门语言的期望太高了，因为它只不过是标准 C 的基础。

那么你在你的代码中使用@private 吗？为什么？

【问题讨论】：

...C++....sane??....doesnotcompute...

好吧，与 Objective C 的理智相比 :) 我现在主要使用 C#。

C++ 与 Objective-C 相比并不健全，只是你对 Objective-C 的了解还不够。 Objective-C 是一门小巧的语言。 :)

我应该发布另一个问题吗？ :)

@Schultz9999：我说的是 C++。我在问在什么情况下有两个同名的私有成员变量有用？如果它们具有相同的名称，为什么它们不是一个常见的或更具有描述性的名称？我问是因为我是 C++ 新手，我想不出有两个同名私有成员变量是个好主意的任何情况。

【参考方案1】：

我想总是使用@private 是个好主意，但我过去从来没有打扰过，因为除了init 和dealloc 方法之外，我通常对几乎所有的ivar 访问都使用属性访问器。所以在实践中，我很少遇到错误访问 ivars 的问题。

另外，如果您的目标是 ios 4+，如果您使用 @synthesize，则无需为属性声明 ivars。

---

我应该注意，如果您正在编写旨在由其他开发人员继承的库代码，则使用 @private 会更重要。

【讨论】：

这是有用的信息 - 我不知道 ivars 在 V4+ 中是可选的。

是的，因为我从不使用 object->ivar，所以我不担心将 ivar 设为私有。

虽然属性不再正式需要 ivars，但没有它们似乎会导致一些 odd behaviours。

合成的 ivars 没有出现在调试器中肯定很烦人。那就是 GDB ——我想知道 LLVM 编译器的 LDB 是否有同样的问题。除非您直接访问超类 ivars，否则该帖子中的第二个烦恼应该没有实际意义，我认为大多数人都避免这样做。

【参考方案2】：

我这样做是出于习惯，但这真的没关系，除非你发布一个二进制框架，其他人会链接 agiast，我很确定你没有这样做。

所有@private 所做的只是限制对象结构成员的可见性（像obj->_ivar 一样访问，而不是[obj getter] 或obj.getter）。这是一个很好的健全性检查，因为如果您尝试在课堂外执行它会出错 - 几乎唯一使用直接结构访问的地方是在实现 NSCoding 或 NSCopying 时，它们仍然可以工作 - 但它没有真的不会给你买太多。

【讨论】：

@private 实际上比obj->_ivar 结构限制更多。在子类的方法中，没有@private，您可以直接访问祖先的ivars，就像它自己的ivars一样，即_parent_ivar而不是self->_parent_ivar。

【参考方案3】：

它只对 Apple 或那些想要在头文件中只向自己公开某些字段的库的人真正有用。我们从不使用它，因为访问器模型允许您公开（或不公开）您想要的内容。既然我有头文件和源文件，那么私有有什么好处呢？ Objective-C 不是 C++，所以 @private 有不同的目的。

【参考方案4】：

在自 1989 年以来我用 Objective-C 编写的所有代码中，我从不费心使用 @public、@protected 或 @private。